6大设计原则总结

末蓝、 2024-03-16 22:24 70阅读 0赞

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

*   *  概述-SOLID
     *  单一职责原则
     *   *  好处
     *  开闭原则
     *   *  为什么要采用开闭原则
         *  如何使用开闭原则
     *  里氏替换原则
     *   *  定义
         *  定义的含义
         *  最佳实践
     *  迪米特法则
     *   *  含义
         *  最佳实践
     *  接口隔离原则
     *   *  定义
         *  含义
         *  最佳实践
     *  依赖倒置原则
     *   *  定义
         *  好处
         *  依赖的三种写法
         *  最佳实践
     *  总体结论

### 概述-SOLID ###

面向对象的设计原则也被称为`SOLID`。  
在设计和开发软件时可以应用这些原则，以便创建易于维护和开发的程序。SOLID最初是由Robert C.Martin所提出的，它们是敏捷软件开发过程的一部分。SOLID原则包括：

> Single Responsibility Principle：单一职责原则  
> Open Closed Principle：开闭原则  
> Liskov Substitution Principle：里氏替换原则  
> Law of Demeter：迪米特法则  
> Interface Segregation Principle：接口隔离原则  
> Dependence Inversion Principle：依赖倒置原则

把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是`SOLID`（solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计。

### 单一职责原则 ###

英文名称是Single Responsibility Principle，简称是SRP。  
单一职责原则的定义是：

> There should never be more than one reason for a class to change.  
> 应该有且仅有一个原因引起类的变更。

#### 好处 ####

单一职责原则有什么好处：

*  类的复杂性降低：实现什么职责都有清晰明确的定义；
 *  可读性提高：复杂性降低，那当然可读性提高了；
 *  可维护性提高：可读性提高，那当然更容易维护了；
 *  变更引起的风险降低：变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

对于单一职责原则，建议如下：

> 接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

### 开闭原则 ###

Open Closed Principle：开闭原则。  
开闭原则是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。  
开闭原则的定义：

> Software entities like classes,modules and functions should be open for extension but closed for modifications.  
> 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

注意：  
开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

#### 为什么要采用开闭原则 ####

开闭原则是非常重要的，可通过以下几个方面来理解其重要性。

1.  开闭原则对测试的影响  
    新增加的类，新增加的测试方法，只要保证新增加类是正确的就可以了。
2.  开闭原则可以提高复用性  
    缩小逻辑粒度，直到一个逻辑不可再拆分为止。
3.  开闭原则可以提高可维护性  
    一款软件投产后，维护人员的工作不仅仅是对数据进行维护，还可能要对程序进行扩展，维护人员最乐意做的事情就是扩展一个类，而不是修改一个类。
4.  面向对象开发的要求  
    在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。

#### 如何使用开闭原则 ####

1.  抽象约束  
    抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：

> 第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；  
> 第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；  
> 第三，抽象层尽量保持稳定，一旦确定即不允许修改。

要实现对扩展开放，首要的前提条件就是抽象约束。

1.  元数据（metadata）控制模块行为  
    尽量使用元数据来控制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。
2.  制定项目章程  
    在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。
3.  封装变化  
    对变化的封装包含两层含义：  
    第一，将相同的变化封装到一个接口或抽象类中；  
    第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

### 里氏替换原则 ###

#### 定义 ####

它有两种定义：  
第一种定义，也是最正宗的定义：

> If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.  
> （如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。）

第二种定义：

> Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.  
> （所有引用基类的地方必须能透明地使用其子类的对象。）

第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

#### 定义的含义 ####

1.  子类必须完全实现父类的方法  
    我们在做系统设计时，经常会定义一个接口或抽象类，然后编码实现，调用类则直接传入接口或抽象类，其实这里已经使用了里氏替换原则。  
    注意：

*  在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
 *  如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

1.  子类可以有自己的个性  
    子类当然可以有自己的行为和外观了，也就是方法和属性，那这里为什么要再提呢？是因为里氏替换原则可以正着用，但是不能反过来用。在子类出现的地方，父类未必就可以胜任。
2.  覆盖或实现父类的方法时输入参数可以被放大
3.  覆写或实现父类的方法时输出结果可以被缩小  
    这是什么意思呢，父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则就要求S必须小于等于T，也就是说，要么S和T是同一个类型，要么S是T的子类，为什么呢？分两种情况，如果是覆写，父类和子类的同名方法的输入参数是相同的，两个方法的范围值S小于等于T，这是覆写的要求，这才是重中之重，子类覆写父类的方法，天经地义。如果是重载，则要求方法的输入参数类型或数量不相同，在里氏替换原则要求下，就是子类的输入参数宽于或等于父类的输入参数，也就是说你写的这个方法是不会被调用的，参考上面讲的前置条件。

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。  
在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美！

#### 最佳实践 ####

在项目中，采用里氏替换原则时，尽量避免子类的“个性”。  
一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀——委屈了点；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离——缺乏类替换的标准。

### 迪米特法则 ###

迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。

> 通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

#### 含义 ####

迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义：

1.  只和朋友交流  
    迪米特法则还有一个英文解释是：Only talk to your immediate friends（只与直接的朋友通信。）  
    什么叫做直接的朋友呢？  
    每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。  
    出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。  
    方法是类的一个行为，类竟然不知道自己的行为与其他类产生依赖关系，这是不允许的，严重违反了迪米特法则。
2.  朋友间也是有距离的  
    一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。
3.  是自己的就是自己的  
    在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
4.  谨慎使用Serializable  
    对象序列化，如果有改动时，客户端和服务端都需要更新；

#### 最佳实践 ####

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。读者在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。

### 接口隔离原则 ###

接口分为两种：

*  实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，这是一种接口。
 *  类接口（Class Interface），Java中经常使用的`interface`关键字定义的接口。

隔离的定义：

*  Clients should not be forced to depend upon interfaces that they don’t use.（客户端不应该依赖它不需要的接口。）
 *  The dependency of one class to another one should depend on the smallest possible interface.（类间的依赖关系应该建立在最小的接口上。）

#### 定义 ####

> 建立单一接口，不要建立臃肿庞大的接口。

接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。

#### 含义 ####

接口隔离原则是对接口进行规范约束，其包含以下4层含义：

1.  接口要尽量小  
    这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。
2.  接口要高内聚  
    什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互。  
    具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
3.  定制服务  
    一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口（并不一定就是Java中定义的Interface，也可能是一个类或单纯的数据交换），我们设计时就需要为各个访问者（即客户端）定制服务，什么是定制服务？定制服务就是单独为一个个体提供优良的服务。  
    我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。采用定制服务就必然有一个要求：只提供访问者需要的方法。
4.  接口设计是有限度的  
    接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测量的标准。

#### 最佳实践 ####

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。

但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：  
一个接口只服务于一个子模块或业务逻辑；  
通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；  
已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；  
了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设计就出自你的手中！  
根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增，开发人员呛死在接口的海洋里；接口粒度太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。

### 依赖倒置原则 ###

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

#### 定义 ####

> High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

翻译过来，包含三层含义：

*  高层模块不应该依赖低层模块，两者都应该依赖其抽象；
 *  抽象不应该依赖细节；
 *  细节应该依赖抽象。

> 高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象？什么又是细节呢？在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。

依赖倒置原则在Java语言中的表现就是：  
模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；  
接口或抽象类不依赖于实现类；  
实现类依赖接口或抽象类。  
更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设计）的精髓之一。

#### 好处 ####

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

注意

> 在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型，如zhangSan的表面类型是IDriver，实际类型是Driver。

两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。  
测试驱动开发，先写好单元测试类，然后再写实现类，这对提高代码的质量有非常大的帮助，特别适合研发类项目或在项目成员整体水平比较低的情况下采用。

#### 依赖的三种写法 ####

1.  构造函数传递依赖对象  
    在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入
2.  Setter方法传递依赖对象  
    在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入。
3.  接口声明依赖对象  
    在接口的方法中声明依赖对象。

#### 最佳实践 ####

依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。  
我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：

*  变量的表面类型尽量是接口或者是抽象类
 *  任何类都不应该从具体类派生
 *  尽量不要覆写基类的方法  
    如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
 *  结合里氏替换原则使用  
    通俗的规则： 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒置原则的核心。

### 总体结论 ###

> 1.  设计是有限度的，不能无限地考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。
> 2.  不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。