学习笔记【软件架构设计原则】

谁践踏了优雅 2022-09-02 14:43 304阅读 0赞

### 文章目录 ###

*  1.开闭原则
 *  2.依赖倒置原则
 *  3.单一职责
 *  4.接口隔离原则
 *  5.迪米特原则
 *  6.里氏替换原则
 *  7.合成复用原则

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pbmcxOTk1MTIyNA_size_16_color_FFFFFF_t_70]

# 1.开闭原则 #

开闭原则(Open-Closed Principle,OCP)是指一个软件实体(类,模块和函数)应该对扩展性开放,对修改关闭,所谓的开闭,也正是对扩展和修改两个行为的一个原则,它强调的用抽象构建框架,用实现扩展细节,可以提高软件系统的可复用性及可维护性.开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定,灵活的系统,例如版本更新,我们尽可能不修改源代码,但是可以增加新功能.

我们举例说明什么是开闭原则，以书店销售书籍为例，其类图如下：

public interface IBook{ 
      public String getName();
      public String getPrice();
      public String getAuthor();
    }
    public class NovelBook implements IBook{ 
       private String name;
       private int price;
       private String author;
    
       public NovelBook(String name,int price,String author){ 
         this.name = name;
         this.price = price;
         this.author = author;
       }
    
       public String getAutor(){ 
         return this.author;
       }
    
       public String getName(){ 
         return this.name;
       }  
    
       public int getPrice(){ 
         return this.price;
       } 
    }
    
      public static void main(Strings[] args){ 
         IBook novel = new NovelBook("笑傲江湖",100,"金庸");
         System.out.println("书籍名字："+novel.getName()+"书籍作者："+novel.getAuthor()+"书籍价格："+novel.getPrice());
       }

项目投产生，书籍正常销售，但是我们经常因为各种原因，要打折来销售书籍，这是一个变化，我们要如何应对这样一个需求变化呢？

我们有下面三种方法可以解决此问题：

修改接口  
在IBook接口中，增加一个方法getOffPrice(),专门用于进行打折处理，所有的实现类实现此方法。但是这样的一个修改方式，实现类NovelBook要修改，同时IBook接口应该是稳定且可靠，不应该经常发生改变，否则接口作为契约的作用就失去了。因此，此方案否定。

修改实现类  
修改NovelBook类的方法，直接在getPrice()方法中实现打折处理。此方法是有问题的，例如我们如果getPrice()方法中只需要读取书籍的打折前的价格呢？这不是有问题吗？当然我们也可以再增加getOffPrice()方法，这也是可以实现其需求，但是这就有二个读取价格的方法，因此，该方案也不是一个最优方案。

通过扩展实现变化  
我们可以增加一个子类OffNovelBook,覆写getPrice方法。此方法修改少，对现有的代码没有影响，风险少，是个好办法。  
下面是修改后的类图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pbmcxOTk1MTIyNA_size_16_color_FFFFFF_t_70 1]

public class OffNovelBook implements NovelBook{ 
    
       public OffNovelBook(String name,int price,String author){ 
          super(name,price,author);
       }
    
       //覆写价格方法，当价格大于40，就打8析，其他价格就打9析
       public int getPrice(){ 
         if(this.price > 40){ 
            return this.price * 0.8;
         }else{ 
            return this.price * 0.9;
         }     
       } 
    }

# 2.依赖倒置原则 #

依赖倒置原则(Dependence Inversion Principle，DIP)是指设计代码结构时,高层模块不应该依赖低层模块,两者都应该依赖其抽象,抽象不应该依赖细节,细节应该依赖抽象,通过依赖倒置,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码可读性和可维护性,并且能降低修改程序所造成的风险

spring里的依赖注入正是用的此原则  
我正在学习java语言和python,学完之后我又想学go语言了,这个时候又得新加方法了,在高层的调用的时候也要追加,非常不稳定.

public class Student { 
    
        public void javaLanguage() { 
            System.out.println("我正在学习 Java语言");
        }
    
        public void pythonLanguage() { 
            System.out.println("我正在学习 Python语言");
        }
            public static void main(String[] args) { 
            Student student = new Student();
            student.javaLanguage();
            student.pythonLanguage();
        }
    
    }

改善后的代码  
这样不管我以后想学什么语言,只要添加一个实现类即可

public interface Language { 
        void study();
    }
    public class JavaLanguage implements Language { 
        @Override
        public void study() { 
            System.out.println("我正在学习 Java语言");
        }
    }
    public class PythonLanguage implements Language { 
        @Override
        public void study() { 
            System.out.println("我正在学习 Python语言");
        }
    }
    public class Student { 
        public void study(Language language) { 
            language.study();
        }
    
        public static void main(String[] args) { 
            Student student = new Student();
            student.study(new JavaLanguage());
            student.study(new PythonLanguage());
        }
    }

# 3.单一职责 #

单一职责(Simple Reponsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因.

假设我们有一个类负责两个职责,一单发生需求变更,修改其中一个逻辑代码,有可能导致另一个职责的功能发生故障,这样一来,这个类就存在两个导致类变更的原因，如何解决这个问题,将两个职责用两个类实现,进行解耦,后期需求变更维护互不影响,这样的设计,可以降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险。

由下代码能看到这个类处理了两种逻辑处理,假设需要修改其中一类处理逻辑,容易带来不可控的风险

public class Course { 
        public void study(String courseName){ 
            if("直播课".equals(courseName)){ 
                System.out.println(courseName+"不能快进");
            }else{ 
                System.out.println(courseName+"可以快进");
            }
        }
    }
       public static void main(String[] args) { 
            Course course=new Course();
            course.study("直播课");
            course.study("录播课");
        }

解耦的代码

public class LiveCourse { 
        public void study(String courseName) { 
            System.out.println(courseName + "不能快进");
        }
    }
    public class ReplayCourse { 
        public void study(String courseName) { 
            System.out.println(courseName + "可以快进");
        }
    }
       public static void main(String[] args) { 
            LiveCourse liveCourse=new LiveCourse();
            liveCourse.study("直播课");
            ReplayCourse replayCourse=new ReplayCourse();
            replayCourse.study("录播课");
        }

# 4.接口隔离原则 #

接口隔离原理(Interface Segregation Principle,ISP)是指用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口,这个原则指导我们在设计接口时应当注意以下几点

*  (1.一个类对另一个类的依赖应该建立在最小的接口之上
 *  (2.建立单一接口,不要建立庞大臃肿的接口
 *  (3.经量细化接口,接口中的方法尽量少(不是越少越好,一定要适度)  
    接口隔离原则符合我们常说的高内聚,低耦合的设计思想,可以使类具有很好的可读性,可扩展性,可维护性。我们在设计接口的时候,需多话时间去思考,要考虑业务模型,包括对一会可能发生变更的地方做一些预判，所以,对于抽象,对于业务模型的理解是非常重要

下面Animal接口定义动物的一些行为，但是鸟不会游泳,所以fly方法是一个空实现

public interface Animal { 
        void eat();
        void fly();
        void swim();
    }
    public class Bird implements Animal { 
    
        @Override
        public void eat() { 
            System.out.println("鸟在吃饭");
        }
        @Override
        public void fly() { 
            System.out.println("鸟在飞");
        }
        @Override
        public void swim() { 
            //不会游泳
        }
    }

针对不同的动物行为定义不同的接口

public interface EatAnimal { 
        void eat();
    }
    public interface FlyAnimal { 
        void fly();
    }
    public interface SwimAnimal { 
        void swim();
    }
    public class NewBird implements EatAnimal,FlyAnimal { 
        @Override
        public void eat() { 
            System.out.println("鸟在吃饭");
        }
        @Override
        public void fly() { 
            System.out.println("鸟在飞");
        }
    }

# 5.迪米特原则 #

迪米特原则(Law ofDemeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Know Principle,LKP),尽量降低类与类之间的耦合度。迪米特原则主要强调:只和朋友交流,不和陌生人交流.出现在成员变量,方法的输入,输出参数中的类都可以称为成员朋友类,而出现在方法体内部的类不属于朋友类.

public class Course { 
    }
    public class TeamLeader { 
        public void checkNumberOfCourses(List<Course> list) { 
            System.out.println("目前已发布的课程数量是:" + list.size());
        }
    }
    public class Boss { 
        public void commandCheckNumber(TeamLeader teamLeader) { 
            List<Course> courseList = Arrays.asList(new Course());
            teamLeader.checkNumberOfCourses(courseList);
        }
    
        public static void main(String[] args) { 
            Boss boss = new Boss();
            TeamLeader teamLeader = new TeamLeader();
            boss.commandCheckNumber(teamLeader);
        }
    }

根据迪米特原则,Boss只想要结果,不需要跟Course直接交流,而TeamLeader统计需要用Course对象,Boss和Course并不是朋友.

优化后的代码

public class TeamLeader { 
        public void checkNumberOfCourses() { 
            List<Course> courseList = Arrays.asList(new Course());
            System.out.println("目前已发布的课程数量是:" + courseList.size());
        }
    }
    public class Boss { 
        public void commandCheckNumber(TeamLeader teamLeader) { 
            teamLeader.checkNumberOfCourses();
        }
        public static void main(String[] args) { 
            Boss boss = new Boss();
            TeamLeader teamLeader = new TeamLeader();
            boss.commandCheckNumber(teamLeader);
        }
    }

# 6.里氏替换原则 #

里氏替换原则(Liskov Substitution Principle,LSP)是指如果对每一个类型为T1的的对象O1都有类型为T2的对象O2,使得以T1定义的所有程序P在所有的对象O1替换成O2时,P的行为没有发生变化,那么类型T2是类型T1的子类型

子类可以替换父类  
继承有一些优点

*  1.提高代码的重用性，子类拥有父类的方法和属性；
 *  2.提高代码的可扩展性，子类可形似于父类，但异于父类，保留自我的特性；

缺点：侵入性、不够灵活、高耦合

*  1.继承是侵入性的，只要继承就必须拥有父类的所有方法和属性，在一定程度上约束了子类，降低了代码的灵活性；
 *  2.增加了耦合，当父类的常量、变量或者方法被修改了，需要考虑子类的修改，所以一旦父类有了变动，很可能会造成  
    非常糟糕的结果，要重构大量的代码。

任何基类可以出现的地方，子类一定可以出现。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受到影响时，即基类随便怎么改动子类都不受此影响，那么基类才能真正被复用

因为继承带来的侵入性，增加了耦合性，也降低了代码灵活性，父类修改代码，子类也会受到影响，此时就需要里氏替换原则。

*  子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。
 *  子类中可以增加自己特有的方法。
 *  当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
 *  当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

public class Rectangle { 
    
        private long height;
        private long width;
    
        public long getHeight() { 
            return height;
        }
    
        public void setHeight(long height) { 
            this.height = height;
        }
    
        public long getWidth() { 
            return width;
        }
    
        public void setWidth(long width) { 
            this.width = width;
        }
    }
    public class Square extends  Rectangle { 
    
        private long length;
    
        public long getLength() { 
            return length;
        }
    
        public void setLength(long length) { 
            this.length = length;
        }
    
        @Override
        public long getHeight() { 
            return super.getHeight();
        }
    
        @Override
        public void setHeight(long height) { 
            super.setHeight(height);
        }
    
        @Override
        public long getWidth() { 
            return super.getWidth();
        }
    
        @Override
        public void setWidth(long width) { 
            super.setWidth(width);
        }
    }
    public class Main { 
        public static void main(String[] args) { 
            Rectangle rectangle=new Rectangle();
            rectangle.setWidth(20);
            rectangle.setHeight(10);
            resize(rectangle);
    
            Square square=new Square();
            square.setLength(10);
            resize(square);
        }
        public static  void resize(Rectangle rectangle){ 
            while (rectangle.getWidth()>=rectangle.getHeight()){ 
                rectangle.setHeight(rectangle.getHeight()+1);
                System.out.println("widht:"+rectangle.getWidth()+",height:"+rectangle.getHeight());
            }
            System.out.println("resize方法结束");
        }
    }

# 7.合成复用原则 #

合成复用原则(Composite/Aggregate Reuse Principle,CARP)是指经量使用对象组合(has-a)/聚合(contanis-a)而不是继承关系达到软件复用的目的,可以使系统更灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的

继承叫做白箱复用,相当于把所有的实现细节暴露给子类,组合/聚合称为黑箱复用,我们无法获取到类以外的对象的实现细节.

public class DBConnection { 
        public  String getConnection(){ 
            return "MySQL数据库连接";
        }
    }
    public class ProductDao { 
    
        private DBConnection dbConnection;
    
        public void setDbConnection(DBConnection dbConnection) { 
            this.dbConnection = dbConnection;
        }
    
        public void addProduct() { 
            String conn = dbConnection.getConnection();
            System.out.println("使用"+conn+"增加产品");
        }
    }

上述代码中DBConnection不是抽象,不便于系统扩展,如果数据库操作层需要指出Oracle数据，虽然我们在DBConnection中增加对Oracle数据库的支持,但是这违背了开闭原则,其实,我们可以不修改Dao的代码,而将DBConnection修改为"“abstract”

修改后的代码

public abstract class DBConnection { 
        public abstract String getConnection();
    }
    public class MysqlConnection extends DBConnection { 
        @Override
        public String getConnection() { 
            return "MySql数据库连接";
        }
    }
    public class OracleConnection extends DBConnection { 
        @Override
        public String getConnection() { 
            return "Oracle数据库连接";
        }
    }
    
    public class ProductDao { 
    
        private DBConnection dbConnection;
    
        public void setDbConnection(DBConnection dbConnection) { 
            this.dbConnection = dbConnection;
        }
    
        public void addProduct() { 
            String conn = dbConnection.getConnection();
            System.out.println("使用"+conn+"增加产品");
        }
    
        public static void main(String[] args) { 
            ProductDao productDao=new ProductDao();
            productDao.setDbConnection(new OracleConnection());
            productDao.addProduct();
        }
    }

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pbmcxOTk1MTIyNA_size_16_color_FFFFFF_t_70]: /images/20220829/7afc4d8eb7364614ae29a463907dde41.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pbmcxOTk1MTIyNA_size_16_color_FFFFFF_t_70 1]: /images/20220829/aa32b368431b4ba7a866e37924902dea.png