软件设计的七大原则

1. 引言

写出高质量、易维护、高可用的代码是每一个程序员的追求，那么，究竟什么样的代码才是易于维护与扩展的好代码呢？本文，我们就来介绍软件开发过程中的七大原则，一同来管窥一二。

2. 软件设计的七大原则

为了指导程序员写出优秀的代码，前人已经为我们总结出了七个原则，他们侧重点不同、关注的角度各异，是我们在日常开发中要时刻思考、尽量遵循的优秀设计：

1. 单一职责原则（SRP）
2. 开闭原则（OCP）
3. 里氏替换原则（LSP）
4. 接口隔离原则（ISP）
5. 依赖倒置原则（DIP）
6. 迪米特法则（LoD）
7. 合成复用原则（CRP）

其中前五个原则就统称为大名鼎鼎的 SOLID 原则。

3. 开闭原则

3.1 原则描述

开闭原则（Open Closed Principle，OCP）是勃兰特·梅耶在他 1988 年的著作《面向对象软件构造》中首次提出的：

软件实体应当对扩展开放，对修改关闭。 Software entities should be open for extension，but closed for modification.

具体含义是：

当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

3.2 原则实现

这一原则的重要性是不言而喻的，谁都希望自己的代码能够在反复迭代的需求中仅通过扩展已有功能就可以满足新的需求，而不是一个简单的新需求就让整个代码必须发生重构。

那么，如何实现这一原则呢？“抽象约束、封装变化”是一个很好的方法。

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

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

4. 里氏替换原则

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 原则实现

我们常常会结合日常生活中对事物的感知来进行软件架构的设计，但这有时会因为违背里氏替换原则而埋下隐患，比如我们设计一个鸟类，他包含几个属性：体重、飞行速度，并且有这两个方法对应的 get、set 方法。那么，对于任何一个鸟类的对象，我们都可以通过路程/飞行速度计算出飞行所需的时间。

然而，对于维护者来说，此时他需要创建一个“鸡”类，由于鸡不会飞，而“鸟”类中没有是否会飞的属性，意即默认“鸟”类的实现均会飞，此时，“鸡”类就不能够作为“鸟”类的子类，否则对于 getFlySpeed() 方法来说，如果“鸡”类的实现返回为 0，那么，就会造成在计算飞行时间时出现除 0 异常。

5. 依赖倒置原则

5.1 原则描述

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

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。 High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions.

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

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

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

5.2 原则实现

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

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

6. 单一职责原则

6.1 原则描述

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

一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。 There should never be more than one reason for a class to change.

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

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

不仅是类的设计，单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

6.2 原则实现

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

例如在创建“程序员”类时，你可能会考虑到程序员需要具有写代码、测试、调试、运行维护等方法，但事实上，写代码的职责与其他职责并不相关，测试、调试的职责也非常独立，运行维护的职责也是同样，因此，如果将“程序员”类拆分为“程序员”类、“测试”类、“运维”类三个类，项目的可维护性便可以大为加强。

7. 接口隔离原则

7.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.

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

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

7.2 原则实现

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

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

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

8. 迪米特法则

8.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.

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

8.2 原则实现

在实际的开发过程中，复杂的依赖关系网往往令人无比抓狂。迪米特法则就是为了解决这一问题而诞生的。

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

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

9. 合成复用原则

9.1 原则描述

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

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

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

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

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

9.2 原则实现

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

考虑一个实现，假设有一个“职员”类，他有四个子类：“HR”类、“RD”类、“QA”类、“SRE”类，这时，新的需求来了，要求每个职员都要拥有性别，那么，此时你如果选择将四个子类进一步派生出“男HR”类、“女HR”类、“男RD”类、“女RD”类……，你所需要维护的类继承层次就有三层，总计九个类，而如果你仅仅在父类中增添一个 gender 属性，整个继承层次并没有发生变化，相较于增加一层类继承层次，可维护性显然要高得多。

附录 -- 参考资料

https://en.wikipedia.org/wiki/SOLID

http://c.biancheng.net/view/1320.html