6大设计原则

1.单一职责原则

● 类的复杂性降低，实现什么职责都有清晰明确的定义；

● 可读性提高，复杂性降低，那当然可读性提高了；

● 可维护性提高，可读性提高，那当然更容易维护了；

● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修

改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大

的帮助。

2.里氏替换原则

在面向对象的语言中，继承是必不可少的、非常优秀的语言机制，它有如下优点：

● 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；

● 提高代码的重用性；

● 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有

父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同；

● 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的

扩展接口都是通过继承父类来完成的；

● 提高产品或项目的开放性。

自然界的所有事物都是优点和缺点并存的，即使是鸡蛋，有时候也能挑出骨头来，继承

的缺点如下：

● 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；

● 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约

束；

● 增强了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在

缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大段的代码需要重构。

● 第一种定义，也是最正宗的定义：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.（所有引用基类的地方必须能透明地使用其子类的

对象。）

第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且

替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但

是，反过来就不行了，有子类出现的地方，父类未必就能适应。

3.依赖倒置原则

● 高层模块不应该依赖低层模块，两者都应该依赖其抽象；

● 抽象不应该依赖细节；

● 细节应该依赖抽象。

● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过

接口或抽象类产生的；

● 接口或抽象类不依赖于实现类；

● 实现类依赖接口或抽象类。

● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备

这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。

● 变量的表面类型尽量是接口或者是抽象类

● 任何类都不应该从具体类派生

● 尽量不要覆写基类的方法

● 结合里氏替换原则使用

4.接口隔离原则

● 实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实

例，它是对一个类型的事物的描述，这是一种接口。比如你定义Person这个类，然后使用

Person zhangSan=new Person()产生了一个实例，这个实例要遵从的标准就是Person这个

类，Person类就是zhangSan的接口。疑惑？看不懂？不要紧，那是因为让Java语言浸染的时间

太长了，只要知道从这个角度来看，Java中的类也是一种接口。

● 类接口（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.

（类间的依赖关系应该建立在最小的接口上。）

● 接口要尽量小

● 接口要高内聚

● 定制服务

● 接口设计是有限度的

● 一个接口只服务于一个子模块或业务逻辑；

● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨

肉”，而不是“肥嘟嘟”的一大堆方法；

● 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化

处理；

● 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的

你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设

计就出自你的手中！

5.迪米特法则

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

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以

提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维

护带来了难度。读者在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚

低耦合。

6.开闭原则

开闭原则的定义已经非常明确地告诉我们：软件实体应该对扩展开放，对修改关闭，其

含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

● 修改接口

● 修改实现类

● 通过扩展实现变化

开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变

更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

● 开闭原则也只是一个原则

开闭原则只是精神口号，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但

是遵循这6大设计原则基本上可以应对大多数变化。因此，我们在项目中应尽量采用这6大原

则，适当时候可以进行扩充，例如通过类文件替换的方式完全可以解决系统中的一些缺陷。

大家在开发中比较常用的修复缺陷的方法就是类替换，比如一个软件产品已经在运行中，发

现了一个缺陷，需要修正怎么办？如果有自动更新功能，则可以下载一个.class文件直接覆

盖原有的class，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文

件的替换方式修正了一个缺陷，当然这种方式也可以应用到项目中，正在运行中的项目发现

需要增加一个新功能，通过修改原有实现类的方式就可以解决这个问题，前提条件是：类必

须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。

● 项目规章非常重要

如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效

的团队文化，章程是一个团队所有成员共同的知识结晶，也是所有成员必须遵守的约定。优

秀的章程能带给项目带来非常多的好处，如提高开发效率、降低缺陷率、提高团队士气、提

高技术成员水平，等等。

● 预知变化

在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生

过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合

现有的需求，还要适应可能发生的变化，这才是一个优良的架构。

开闭原则是一个终极目标，任何人包括大师级人物都无法百分之百做到，但朝这个方向

努力，可以非常显著地改善一个系统的架构，真正做到“拥抱变化”。