《设计模式之禅》——6大设计原则

1.单一职责原则(源码)

       定义：一个类只负责一个功能领域中的相应职责，或者就一个类而言，应该只有一个引起它变化的原因。

单一职责原则的优点：  

•  可以降低类的复杂度，实现什么职责都有清晰明确的定义；
•  提高类的可读性；
•  提高系统的可维护性；
•  变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，一个接口修改只对相应地实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

2.里氏替换原则(源码)

       定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

       里氏替换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

       里氏替换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

里氏代换原则为良好的继承定义了一个规范，它包含了4层定义：

1. 子类必须完全实现父类的方法。
2. 子类可以有自己的个性
3. 覆盖或实现父类的方法时输入参数可以被放大
4. 覆写或实现父类的方法时输出结果可以被缩小

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

3.依赖倒置原则(源码)

        定义：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

        依赖倒置原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。
        依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。在项目中使用，我们只要遵循以下几个规则就可以：

1. 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
2. 变量的表名类型尽量是接口或者抽象类。
3. 任何类都不应该从具体类派生。
4. 尽量不要覆写基类的方法。
5. 结合里氏替换原则使用

4.接口隔离原则(源码)

        定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
        根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。看到这里好像接口隔离原则与单一职责原则是相同的。其实接口隔离原则与单一职责原则的审视角度是不相同的，单一职责原则要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。

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

1.  接口要尽量少。
2.  接口要高内聚。
3.  定制服务。
4.  接口设计师有限度的。

        在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。

        接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量.

1.   一个接口只服务于一个子模块或业务逻辑。
2.  通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法。
3.  已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。
4.  了解环境，拒绝盲从。 环境不同，接口拆分的标准就不同，深入了解业务逻辑，根据实际情况设计接口。

5.迪米特法则(源码)

        定义：一个软件实体应当尽可能少地与其他实体发生相互作用。
        迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
        在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
        迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。我们在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。

6.开闭原则(源码)

        定义：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

        根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。这也是系统设计需要遵循开闭原则的原因：
        1）稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。
        2）扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。

如何使用开闭原则：

1. 抽象约束。首先通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型，引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定既不允许修改。
2. 元数据(metadata)控制模块行为。尽量使用元数据(用来描述环境和数据的数据，通俗的说就是配置参数)来控制程序的行为，减少重复开发。
3. 制定项目章程。对于项目来说，约定优于配置。
4. 封装变化。第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

其它内容戳这里。