软件设计原则

1. 引言

经过多年项目开发和对优秀项目源码的学习，总有一种体会：“优秀的项目大体是相同的，糟糕的项目各有各的不足”，这种体会促使我去思考这些优秀项目拥有的共同优秀品质，现在仔细想来共同遵守软件设计原则就是它们的优秀品质之一，这些原则包含了计算机先驱对 "从术到道"的追求的思考。

前五大原则便是大名鼎鼎的 “SOLID” 原则

2. 单一职责原则 SRP

2.1 定义

单一职责原则（Single Responsibility Principle，SRP）由罗伯特·C·马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的：

一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

There should never be more than one reason for a class to change.

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力。
2. 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

不仅是类的设计，单一职责同样也适用于方法，一个方法应该尽可能做好一件事情。

2.2 实现

当一个类只具有一个职责时，那么当这个职责发生变化，我们可以非常肯定地说没有其他类需要变更，这在可维护性上来说是很强的。

比如创建一个 “程序员” 类，你可能考虑程序员包含代码、测试、运行维护等方法，但实际上代码、测试和运行维护职责互不相关，因此可将 “程序员” 类拆分为 “程序员” 类、“测试” 类 和 “运维” 类。

3. 开闭原则 OCP

3.1 定义

开闭原则（Open Closed Principle，OCP）是勃兰特·梅耶在他 1988 年的著作《面向对象软件构造》中首次提出的：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

软件实体应当对扩展开放，对修改关闭。

Software entities should be open for extension，but closed for modification.

3.2 实现

“抽象约束、封装变化” 是一种实现开闭原则的好方式：

通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

只要抽象层能够覆盖足够多的场景，那么，即使实现层无法满足新的需求，也只需要扩展实现层即可，而不需要改变底层的抽象设计。

4. 里氏替换原则 LSP

4.1 定义

里氏替换原则（Liskov Substitution Principle，LSP）是由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的：

继承必须确保超类所拥有的性质在子类中仍然成立。

Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.

简单的来说，这个原则是说子类在继承父类时，不要改变父类原有的功能（尽量不重写）。

具体的来说，这个原则可以被总结为以下四点：

1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；
2. 子类中可以增加自己特有的方法；
3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松；
4. 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等。

如果程序违背了里氏替换原则，那么在多态环境下，代码维护者由于遇到父子类行为的不一致，很容易陷入迷惑的境地，程序运行的出错概率也就随即大幅提升。

4.2 实现

我们常常会结合日常生活中对事物的感知来进行软件架构的设计，但这有时会因为违背里氏替换原则而埋下隐患。比如企鹅、鸵鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承 “鸟” 会飞的功能，所以它们不能定义成 “鸟” 的子类。

5. 接口隔离原则 ISP

5.1 定义

接口隔离原则（Interface Segregation Principle，ISP）是 2002 年罗伯特·C·马丁提出的：

客户端不应该被迫依赖于它不使用的方法。

Clients should not be forced to depend on methods they do not use.

这个原则也被描述为：

一个类对另一个类的依赖应该建立在最小的接口上。

The dependency of one class to another one should depend on the smallest possible interface.

如果能够遵循这一原则，模块间的依赖粒度得以最小化，那么，如果某个模块发生变更，其他模块受到的影响就会显著变小，外来变更就不会因此扩散到过大的范围，从而让项目的可维护性提升至非常高的维度。

这个原则也很有力的保障了模块间的低耦合与模块内的高内聚。

5.2 实现

在具体的实现中，我们可以尽量遵循以下四个规则：

1. 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
2. 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
3. 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
4. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

如果系统中某个模块随着业务的发展越来越庞大，适时地拆分是扼杀危险的有效手段。对模块功能进行归类，从而拆分出几个高度内聚的模块，非常有利于系统的发展

举个例子，如果我们想定义一个汽车接口包含加油、充电、加气方法，实际上我们应该拆分为油车、电车、气车三个接口。

6. 依赖倒置原则 DIP

6.1 定义

依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C. Martin）于 1996 年在 C++ Report 上发表的文章中首次提出的：

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

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.

简单的总结，这个原则就是：

要面向接口编程，不要面向实现编程。

在实际的软件设计中，实现是多变的，抽象层是稳定的，因此，让模块间都通过抽象的接口或是抽象类来描述依赖，可以很大程度上降低开发风险，提升稳定性，同时也是模块间解耦的有力方法。

6.2 实现

遵循以下四点，就能在项目中满足依赖倒置规则：

1. 每个类尽量提供接口或抽象类，或者两者都具备。
2. 变量的声明类型尽量是接口或者是抽象类。
3. 任何类都不应该从具体类派生。
4. 使用继承时尽量遵循里氏替换原则。

7. 迪米特法则 LOD

7.1 定义

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知：

只与你的直接朋友交谈，不跟“陌生人”说话。

Talk only to your immediate friends and not to strangers.

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

7.2 实现

如果你设计每个类的每个方法时都问问自己：我引入的依赖是该依赖的对象吗？我暴露的方法是应该暴露的吗？那么，你的设计一定会有显著提升。

即便是必要依赖，也要尽量降低依赖的次数，尤其是尽量不要在模块间传递序列化后的数据，由于过度泛化造成的类型不清晰，可能会让你的系统产生难以预想的问题。

假设一个场景老师叫班长去收学生作业，在这个场景中 “老师” 类和 “班长” 类直接通信, “班长” 类和 “学生” 类直接通信，而 “老师” 类与 “学生” 类无直接通信，因此在 “班长” 类收作业的方法中只需返回结果即可。

比如有三个类 A、B、C，现在 A 类只需要调用 B 类的方法，B 类则去调用 C 类的属性，如果此时 A 类中出现了 C 类的对象，就相当于 A 类和 C 类发生了耦合关系，但实际上两者并不相关，并没有联系。此时 B 类应该完成处理 C 类的属性以及方法再将结果返回给 A 类，而 A 类也不需要出现 C 类即可。

8. 合成复用原则 CRP

8.1 定义

合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP），它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

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

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

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

8.2 实现

当需要扩展一个类时，优先通过类属性来进行扩展，而不是通过派生新的子类。

参考资料

1. 软件设计的七大原则
2. 深度总结：软件设计七大原则