面向对象的五大基本设计原则：SOLID

什么是设计原则？

⾯向对象过程中，前辈⼤咖们推荐的⼀些 指导性原则 ，遵循这些原则可以让你的设计更有竞争力。

S.O.L.I.D 是面向对象设计（OOD）的头五大基本原则的首字母缩写，由俗称「鲍勃大叔」的 Robert C. Martin 

提出。这些原则，结合在一起能够方便程序员开发易于维护和扩展的软件，也让开发人员轻松避免代码异味，易于重构代码，

也是敏捷或自适应软件开发的一部分。

注意：这只是一篇“欢迎来到S.O.L.I.D”的简单介绍文章，它只是揭示了S.O.L.I.D是什么。

S.O.L.I.D代表什么:

虽然缩略词展开后看似复杂，但其实非常容易掌握。

S – 单一职责原则
O – 开放封闭原则
L – 里氏替换原则
I – 接口隔离原则
D – 依赖倒置原则
让我们来单独看看每个原则，来理解为什么 S.O.L.I.D 能帮助我们成为更优秀的开发人员。

五大基本原则：

一、单⼀职责原则（SRP：Single Responsibility Principle）

背景：

单⼀职责原则，SRP⼜称单⼀功能原则，⾯向对象五个基本原则（SOLID）之⼀。它规定⼀个类应

该只有⼀个发⽣变化的原因。该原则由罗伯特·C·⻢丁（Robert C. Martin）于《敏捷软件开发：原

则、模式和实践》⼀书中给出的。

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

定义：

1.⼀个模块只负责⼀件事。

2.⼀个类只负责⼀件事。

3.⼀个⽅法只负责⼀件事。

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

如何遵守单⼀职责原则:

1.定义抽象⽗类 or ⽗类虚⽅法

2.⼦类继承后重写，不同的实现

何时遵循？何时不遵守？

1.类型逻辑⾜够简单，⽅法⾜够少，可以不遵守

2.类型复杂，⽅法很多，⼀定要遵循单⼀职责原则

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

单⼀职责的优缺点:

优点

1,每个类相对简单，只负责⾃⼰的事情。

2.需求变更时，只修改变更类，其他类不受影响。

缺点

1.代码量会有所增加

2.解读代码成本增加

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

单⼀职责的不同层⾯:

1.以⽅法为单位

⼀个⽅法只负责⼀件事 ⽅法中可以封装成⼀个新⽅法的，就封装成⼀个新⽅法

2.以类为单位

⼀个类只负责⼀件事

不属于该类的内容，创建新的类去封装

3.以模块 / 项⽬为单位

⼀个模块 / 项⽬只负责⼀件事

不属于该模块的内容，交由属于的模块去负责

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

常⻅违背单⼀职责场景:

1.在⽅法中出现多个分⽀，分别去执⾏各⾃的逻辑，功能虽然可以实现。

2.但如果需求变更，就会⾮常的不稳定。

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

实例：不同动物的叫声处理，喊叫⽅法中多个分⽀，还是不同类不同喊叫⽅法。

二、⾥⽒替换原则（LSP：Liskov Substitution Principle）

背景：

⾥⽒替换原则， LSP 作为 OO 的⾼层原则，主张使⽤ “ 抽象 (Abstraction)” 和 “ 多态 (Polymorphism)” 将

设计中的静态结构改为动态结构，维持设计的封闭性。 “ 抽象 ” 是语⾔提供的功能。 “ 多态 ” 由继承语

义实现。

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

定义：

1.任何使⽤基类的地⽅，都可以安全的去使⽤其⼦类。

2.⽗类有的内容，⼦类必须有【类的强继承】

3.如果⽗类出现了⼦类不应该有的内容，那么就应该断开两个类的继承关系 。然后，重新创建新的

⽗类，包含⼦类该拥有的内容

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

⼦类必须有⾃⼰的⾏为和特征：

1.⽗类已经实现的内容，⼦类不要再写【 不要使⽤ new 关键词隐藏⽗类⽅法 】

2.如果⼦类希望可以重写⽗类⽅法，⽗类⽅法⽤ abstruct 或 virtual 修饰

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

实例：游戏⻆⾊中的攻击⽅法，不能被不能攻击的⼦类继承。

三、依赖倒置原则（DIP：Dependence Inversion Principle）

背景：

依赖倒置原则（ Dependence Inversion Principle ）是程序要依赖于抽象接⼝，不要依赖于具体实

现。简单的说就是要求对抽象进⾏编程，不要对实现进⾏编程，这样就降低了客户与实现模块间的

耦合。

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

定义：

⾼层模块不应该依赖于低层模块，两者应该 依赖抽象 ，⽽不是依赖细节。

⾼层：⽅法调⽤⽅

底层：被调⽤⽅

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

⾯向抽象编程：

1.属性、字段、⽅法参数、返回值，⼀切都尽量使⽤抽象【类 / 接⼝】

2.抽象不变，⾼层就不变

3.抽象⼀般是稳定的，低层的扩展变化不会影响到⾼层，低层就可以横向的⾃由扩展，架构稳定

80% 的设计模式跟抽象有关

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

抽象的好处：

1.⼀个⽅法可以满⾜不同类型的参数传⼊

2.⽀持动态扩展，只要是实现了这个抽象，不需要修改上层

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

实例：学⽣类实现不同⼿机的使⽤⽅法，学⽣依赖⼿机，新⼿机出现时，学⽣类也要更新新⽅法。

不同的⼿机应该依赖抽象（⼿机），学⽣类也应该依赖于抽象（⼿机⽤户）

四、接⼝隔离原则（ISP：Interface Segregation Principle）

背景：

客户端不应该依赖它不需要的接⼝。⼀个类对另⼀个类的依赖应该建⽴在最⼩的接⼝上。

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

定义：

1.使⽤多个专⻔的接⼝⽐使⽤单⼀的总接⼝要好，但也不建议⼀个接⼝只对应⼀个⽅法。

2.⼀个类对另外⼀个类的依赖性应当是建⽴在 最⼩的接⼝ 上的。

3.⼀个接⼝代表⼀个⻆⾊，不应当将不同的⻆⾊都交给⼀个接⼝。没有关系的接⼝合并在⼀起，

形成⼀个臃肿的⼤接⼝，这是对⻆⾊和接⼝的污染。

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

接⼝的正确定义：

1.既不能⼤⽽全，也建议不能⼀个接⼝⼀个⽅法

2.应该按照功能的密不可分来定义接⼝

3.应该是动态的，随业务变化⽽变化，设计的时候要留好提前量，避免抽象的变化

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

实例：⼿机的核⼼功能就是打电话和发短信，拍照、上⽹等其他功能的接⼝，不要被⼿机所依赖。 参看 .Net 类中的接⼝的设计与实现

五、开闭原则（OCP：Open Closed Principle）【总则】

背景：

在⾯向对象编程领域中，开闭原则规定 “ 软件中的对象（类，模块，函数等等）应该对于扩展是开

放的，但是对于修改是封闭的 ” ，这意味着⼀个实体是允许在不改变它的源代码的前提下变更它的

⾏为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元

测试以及诸如此类的⽤以确保产品使⽤质量的过程。遵循这种原则的代码在扩展时并不发⽣改变，

因此⽆需上述的过程。

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

定义：

对扩展开放，对修改关闭

扩展：添加新代码（类）

修改：修改原代码（类）

开闭原则是⼀个⽬标，没有任何⼿段，⼜被称为总则。

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

为什么要遵循开闭原则：

⾯向对象语⾔是静态语⾔，最害怕变化，因为会波及很多东⻄。

最理想的就是新增类，对原代码没有改动，原有代码才是可信的。

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

遇到需求变更该怎么办呢：

直接修改现有⽅法（最不可取）

增加⽅法（稍好⼀些）

增加类 （那更好啦）

增加类库 / 框架（那最好啦）

其他原则：

一、迪⽶特原则（LKP：Least Knowledge Principle ）

背景：

迪⽶特法则（ Law of Demeter ）⼜叫作最少知识原则（ Least Knowledge Principle 简写 LKP ），

⼀个类对于其他类知道的越少越好，就是说⼀个对象应当对其他对象有尽可能少的了解，只和朋友

通信，不和陌⽣⼈说话。

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

定义：

⼀个对象应该对其他对象保持 最少的了解 ，只与直接朋友进⾏通信。

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

类与类之间的关系：

纵向：继承关系

横向：聚合、组合、关联、 依赖 「出现在⽅法内部」

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

⾼内聚、低耦合

降低耦合度的⽅法

1. 少使⽤类的继承，多⽤接⼝隐藏实现的细节。

2. 模块的功能化分尽可能的单⼀，道理也很简单，功能单⼀的模块供其它模块调⽤的机会就少。（其

实这是⾼内聚的⼀种说法，⾼内聚低耦合⼀般同时出现）。

3. 遵循⼀个定义只在⼀个地⽅出现。

4. 少使⽤全局变量。

5. 类属性和⽅法的声明少⽤ public ，多⽤ private 关键字。

6. 多⽤设计模式，⽐如采⽤ MVC 的设计模式就可以降低界⾯与业务逻辑的耦合度。

7. 尽量不⽤ “ 硬编码 ” 的⽅式写程序，同时也尽量避免直接⽤ SQL 语句操作数据库。

8. 最后当然就是避免直接操作或调⽤其它模块或类（内容耦合）；如果模块间必须存在耦合，原则上

尽量使⽤数据耦合，少⽤控制耦合，限制公共耦合的范围，避免使⽤内容耦合。

增强内聚度⽅法

1. 模块只对外暴露最⼩限度的接⼝，形成最低的依赖关系。

2. 只要对外接⼝不变，模块内部的修改，就不得影响其他模块。

3. 删除⼀个模块，应当只影响有依赖关系的其他模块，⽽不应该影响其他⽆关部分。

4.通过降低访问修饰符权限，减少联系，减少耦合

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

实例：学校介绍 -> 班级介绍 -> 学⽣介绍，两两联系，学校不要与学⽣直接联系

二、合成复用原则（CRP: Composite Reuse Principle）

合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，

使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。

又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。

它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

简言之：要尽量使用组合/聚合关系，少用继承。

合成复用原则的重要性：

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。

1. 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
2. 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
3. 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。

1. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
2. 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
3. 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

合成复用原则的实现方法：

合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

下面以汽车分类管理程序为例来介绍合成复用原则的应用。

【例1】汽车分类管理程序。

分析：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。图 1 所示是用继承关系实现的汽车分类的类图。
 

图1 用继承关系实现的汽车分类的类图

从图 1 可以看出用继承关系实现会产生很多子类，而且增加新的“动力源”或者增加新的“颜色”都要修改源代码，这违背了开闭原则，显然不可取。但如果改用组合关系实现就能很好地解决以上问题，其类图如图 2 所示。
 

图2 用组合关系实现的汽车分类的类图