七大软件架构设计原则

水深无声 2024-03-26 12:50 18阅读 0赞

#### 文章目录 ####

*  开闭原则（Open-Closed Principle，OCP）
 *  依赖倒置原则（Dependence Inversion Principle，DIP）
 *  单一职责原则（Simple Responsibility Principle，SRP）
 *  接口隔离原则（Interface Segregation Principle，ISP）
 *  里氏替换原则（Liskov Substitution Principle，LSP）
 *  合成复用原则（Composite/Aggregate Reuse Principle，CARP）
 *  迪米特法则（Law of Demeter，LoD）又叫作最少知道原则（Least Knowledge Principle，LKP）
 *  总结

--------------------

## 开闭原则（Open-Closed Principle，OCP） ##

一个软件实体如**类、模块和函数应该对扩展开放，对修改关闭**。如：版本更新，我们尽可能不修改源码，但是可以增加新功能。

例1：

1、课程接口ICourse
    public interface ICourse {
        
       Double getPrice();
    }
    
    2、他有一个Java架构课程的类JavaCourse
    public class JavaCourse implements ICourse {
        
        public Double price;
        
        public JavaCourse(Double price) {
        
            this.price = price;
        }
        
        @Override
        public Double getPrice() {
        
            return price;
        }
    }
    
    3、现在要给Java架构课程做活动，价格优惠。
    如果修改JavaCourse中的getPrice()方法，则会存在一定风险，可能影响其他地方的调用结果。
    如何在不修改原有代码的前提下，实现价格优惠这个功能呢？
    
    4、我们再写一个处理优惠逻辑的JavaDiscountCourse类，而不是直接修改JavaCourse类
    public class JavaDiscountCourse extends JavaCourse {
        
        public JavaDiscountCourse(Double price) {
        
            super(price);
        }
        
        public Double getDiscountPrice(Double discountRate) {
        
            return price * discountRate;
        }
        
        public Double getOriginPrice() {
        
            return price;
        }
    }

--------------------

## 依赖倒置原则（Dependence Inversion Principle，DIP） ##

**a.指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象**  
**b.抽象不应该依赖细节，细节应该依赖抽象**

通过依赖倒置，可以降低类与类之间的`耦合性`，提高系统的`稳定性`，`可读性`,`可维护性`

`以抽象为基准`比`以细节为基准`搭建起来的架构要稳定得多。因此大家在拿到需求后，要面向接口编程，按照`先顶层再细节`的顺序设计代码结构

例1：

public class Tom {
        
        public void studyEnglish(){
        }
        public void studyChinese(){
        }
    }
    
    Tom tom = new Tom();
    tom.studyEnglish();
    tom.studyChinese();
    
    Tom再追加学习画画的话。在Tom类中增加studyDraw()的方法，在高层也要追加调用。
    如此一来，在修改代码的同时会带来意想不到的风险。

优化成如下方式
    
    public interface ICourse {
        
        void study();
    }
    
    public class ChineseCourse implements ICourse {
        
        @Override
        public void study() {
        
        }
    }
    
    public class EnglishCourse implements ICourse {
        
        @Override
        public void study() {
        
        }
    }
    
    public class Daming {
        
        void study(ICourse course){
        
            course.study();
        }
    }
    
    Daming daming = new Daming();
    daming.study(new ChineseCourse());
    daming.study(new EnglishCourse());

--------------------

## 单一职责原则（Simple Responsibility Principle，SRP） ##

**指不要存在一个以上导致类变更的原因**

> 假设有一个Class负责两个职责，这个Class就存在两个导致类变更的原因。一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。

**如何解决这个问题呢？**

> 我们就要分别用两个Class来实现两个职责，进行解耦。

**总体来说就是一个Class、Interface、Method只负责一项职责**

> 在实际项目中，代码会存在依赖、组合、聚合关系，在项目开发过程中还受到项目的规模、周期、技术人员水平、对进度把控的影响，导致很多类都不能满足单一职责原则。  
> 但是，我们在编写代码的过程中，**尽可能地让接口和方法保持单一职责**，对项目后期的维护是有很大帮助的。

--------------------

## 接口隔离原则（Interface Segregation Principle，ISP） ##

**a.用多个专门的接口，而不使用单一的总接口**  
**b.客户端不应该依赖它不需要的接口**

接口隔离原则符合“**高聚合、低耦合**”的设计思想，使得类具有很好的`可扩展性`,`可读性`,`可维护性`。

在设计接口的时候，要多花时间思考，要考虑业务模型，包括还要对以后可能发生变更的地方做一些预判。  
所以，在实际开发中，我们对抽象、业务模型的理解是非常重要的。

例1：

public interface IAnimal {
        
        void fly();
        void swim();
        void run();
    }
    
    大多数时候鸟类的swim()方法只能空着，陆地动物的fly()方法只能空着,代表接口就有些臃肿了。
    这时候，我们针对不同动物的行为来设计不同的接口
    
    public interface IFlyAnimal {
        
        void fly();
    }
    public interface IRunAnimal {
        
        void run();
    }
    public interface ISwimAnimal {
        
        void swim();
    }

--------------------

## 里氏替换原则（Liskov Substitution Principle，LSP） ##

> 指如果对每一个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P，在所有对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的`子类型`

**子类可以扩展父类的功能，但不能改变父类原有的功能**

> **根据这个理解，我们对里氏替换原则的定义总结如下**  
> 1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。  
> 2）子类中可以增加自己特有的方法。  
> 3）当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松。  
> 4）当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类的方法更严格或相等。

> **使用里氏替换原则有以下优点**  
> 1）`约束继承泛滥`，是`开闭原则`的一种体现。  
> 2）加强程序的`健壮性`，`兼容性`，`维护性`、`可扩展性`

例1：

public class JavaCourse implements ICourse {
        
        public Double price;
        
        public JavaCourse(Double price) {
        
            this.price = price;
        }
        @Override
        public Double getPrice() {
        
            return price;
        }
    }
    
    public class JavaDiscountCourse extends JavaCourse {
        
        public JavaDiscountCourse(Double price) {
        
            super(price);
        }
        
        public Double getDiscountPrice(Double discountRate) {
        
            return price * discountRate;
        }
        
        public Double getOriginPrice() {
        
            return price;
        }
    }
    
    getOriginPrice() 就是典型的违反了里氏替换原则。我们不应该覆盖 getPrice()方法
    
    public class JavaDiscountCourse extends JavaCourse {
        
        public JavaDiscountCourse(Double price) {
        
            super(price);
        }
        
        public Double getDiscountPrice(Double discountRate) {
        
            return price * discountRate;
        }
        
        public Double getPrice() {
        
            return price;
        }
    }

--------------------

## 合成复用原则（Composite/Aggregate Reuse Principle，CARP） ##

**指尽量使用对象组合（has-a）或对象聚合（contanis-a）的方式实现代码复用，而不是用继承关系达到代码复用的目的。**

继承，又被称为白箱复用，相当于把所有实现细节暴露给子类。  
组合/聚合又被称为黑箱复用，对类以外的对象是无法获取实现细节的。

--------------------

## 迪米特法则（Law of Demeter，LoD）又叫作最少知道原则（Least Knowledge Principle，LKP） ##

**指一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合**

> 出现在`成员变量`、方法的`输入参数`和`输出参数`中的类都可以被称为成员朋友类，而出现在方法体内部的类不属于朋友类

例1：

public class Task {
        }
    
    public class Employee {
        
    	// 员工检查数据操作
        void checkTask(List<Task> tasks){
        }
    }
    
    public class Leader {
        
        public void commandCheck(Employee employee){
        
            // 获取数据
            List<Task> taskList = new ArrayList<>();
    
            // 让员工去检查任务
            employee.checkTask(taskList);
        }
    }
    
    Leader leader = new Leader();
    Employee employee = new Employee();
    leader.commandCheck(employee);
    
    代码实际意义：领导吩咐员工检查任务
    根据迪米特法则，TeamLeader和Task并不是朋友。Leader只想要结果，不需要跟Task产生直接交流。
    PS：领导让你统计报表你让老板去替你收集数据也说不过去
    
    public class Employee {
        
        void checkTask1(){
        
            // 获取数据
            List<Task> taskList = getTaskList();
            
            // 检查的逻辑处理了
            ...
        }
    }
    
    public class Leader {
        
        public void commandCheck1(Employee employee){
        
            employee.checkTask1();
        }
    }
    
    Leader leader = new Leader();
    Employee employee1 = new Employee();
    leader.commandCheck1(employee1);
    
    领导发话就可以了，不需要做任何员工的任务量

--------------------

## 总结 ##

![在这里插入图片描述][f29a293a09bd4dbd88e49f410b5bce95.png]

\-----------------------------------------------------------------------------摘自《设计模式就该这样学：基于经典框架源码和真实业务场景》（谭勇德）

[f29a293a09bd4dbd88e49f410b5bce95.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/4440c80bd56c4dfd9debb314ba1221c0.png