研磨设计模式 之 附录一 常见面向对象设计原则——跟着cc学设计系列

26.1  设计模式和设计原则

26.1.1  设计模式和设计原则的关系

面向对象的分析设计有很多原则，这些原则大都从思想层面，给我们指出了面向对象分析设计的正确方向，是我们进行面向对象分析设计应该尽力遵守的准则。

       而设计模式已经是针对某个场景下某些问题的某个解决方案。也就是说这些设计原则是思想上的指导，而设计模式是实现上的手段，因此设计模式也是应该遵守这些原则的，换句话说，设计模式就是这些设计原则的一些具体体现。

26.1.2  为何不重点讲设计原则

       既然设计模式是这些设计原则的具体体现，那也就意味着设计模式的思想上的根就是这些设计原则了，没错，可以这么认为。

这样一来，有些朋友就会很疑惑了，那么为何不重点讲讲设计原则呢？对于这个问题，我们有如下的考虑：

• 设计原则本身是从思想层面上进行指导，本身是高度概括和原则性的，只是一个设计上的大体方向，其具体实现并不是只有设计模式这一种。理论上来说，可以在相同的原则指导下，做出很多不同的实现来。
• 每一种设计模式并不是单一的体现某一个设计原则，事实上，很多设计模式都是融合了很多个设计原则的思想，并不好特别强调设计模式对某个或者是某些设计原则的体现。而且每个设计模式在应用的时候也会有很多的考量，不同使用场景下，突出体现的设计原则也可能是不一样的。
• 这些设计原则只是一个建议指导，事实上，在实际开发中，很少做到完全遵守，总是在有意无意的违反一些或者是部分设计原则。设计工作本来就是一个不断权衡的工作，有句话说得很好：“设计是一种危险的平衡艺术”，设计原则只是一个指导，有些时候，还要综合考虑业务功能、实现的难度、系统性能、时间与空间等很多方面的问题
• 设计模式本身已经很复杂了，在一本书里面很难再去深入的探讨这些设计原则，这样也避免出现过多的重点内容，导致大家无所适从

本书的目标是想与朋友们深入的探讨设计模式而不是设计原则，因此我们选择弱讲设计原则。事实上，就算你不懂这些设计原则，对本书的阅读也没有太大的影响，只是在一些问题认识的深度上可能会有一点阻碍。基于同样的道理，这里也没有过多从重构的角度去讲述设计模式。

当然，在某些设计模式里面，明显的体现了某些设计原则，我们也还是会与朋友们一起来讨论和分享的。

这里为不熟悉这些设计原则的朋友，简要准备了一些常见的、基本的面向对象设计原则的知识，可以先阅读这些内容，然后再回去看设计模式的内容，可能会有一定的帮助。但请注意，这并不是面向对象设计原则的全部，更多的知识，有机会再与朋友们一起分享。

26.2  常见的面向对象设计原则

26.2.1  单一职责原则SRP（Single Responsibility Principle）

所谓单一职责原则，指的就是：一个类应该仅有一个引起它变化的原因。

这里变化的原因就是所说的“职责”，如果一个类有多个引起它变化的原因，那么也就意味着这个类有多个职责，再进一步说，就是把多个职责耦合在一起了。

这会造成职责的相互影响，可能一个职责的变化，会影响到其它职责的实现，甚至引起其它职责跟着变化，这种设计是很脆弱的。

这个原则看起来是最简单和最好理解的，但是实际上是很难完全做到的，难点在于如何区分这个“职责”，这是个没有标准量化的东西，哪些算职责，到底这个职责有多大的粒度，这个职责如何细化等等。因此，在实际开发中，这个原则也是最容易违反的。

26.2.2  开放-关闭原则OCP（Open-Closed Principle）

       所谓开放-关闭原则，指的就是：一个类应该对扩展开放，对修改关闭。一般也被简称为开闭原则，开闭原则是设计中非常核心的一个原则。

       开闭原则要求的是，类的行为是可以扩展的，而且是在不修改已有的代码的情况下进行扩展，也不必改动已有的源代码或者二进制代码。

       看起来好像是矛盾的，怎么样才能实现呢？

实现开闭原则的关键就在于合理的抽象，分离出变化与不变化的部分，为变化的部分预留下可扩展的方式，比如：钩子方法、或是动态组合对象等等。

       这个原则看起来也很简单，但事实上，一个系统要全部做到遵守开闭原则，几乎是不可能的，也没这个必要。适度的抽象可以提高系统的灵活性，使其可扩展、可维护，但是过度的抽象，会大大增加系统的复杂程度。应该在需要改变的地方应用开闭原则就可以了，而不用到处使用，从而陷入过度设计。

26.2.3  里氏替换原则LSP（Liskov Substitution Principle）

       所谓里氏替换原则，指的就是：子类型必须能够替换掉它们的父类型。这很明显是一种多态的使用情况，它可以避免在多态的应用中，出现某些隐蔽的错误。

事实上，当一个类继承了另外一个类，那么子类就拥有了父类中可以继承下来的属性和操作，理论上来说，此时使用子类型去替换掉父类型，应该不会引起原来使用父类型的程序出现错误。

但是，很不幸的是，在某些情况下是会出现问题的，比如：如果子类型覆盖了父类型的某些方法，或者是子类型修改了父类型某些属性的值，那么原来使用父类型的程序就可能会出现错误，因为在运行期间，从表面上看，它调用的是父类型的方法，需要的是父类型方法实现的功能，但是实际运行调用的确是子类型覆盖实现的方法，而该方法跟父类型的方法并不一样，那就会导致错误的产生。

从另外一个角度来说，里氏替换原则是实现开闭的主要原则之一，开闭原则要求对扩展开放，扩展的一个实现手段就是使用继承，而里氏替换原则是保证子类型能够正确替换父类型，只有能正确替换，才能实现扩展，否则扩展了也会出现错误。

26.2.4  依赖倒置原则DIP（Dependence Inversion Principle）

       所谓依赖倒置原则，指的就是：要依赖于抽象，不要依赖于具体类。要做到依赖倒置，典型的应该做到：

• 高层模块不应该依赖于底层模块，二者都应该依赖于抽象
• 抽象不应该依赖于具体实现，具体实现应该依赖于抽象

       很多人觉得，层次化调用的时候，应该是高层调用“底层所拥有的接口”，这是一种典型的误解。事实上，一般高层模块包含对业务功能的处理和业务策略选择，应该被重用，应该是高层模块去影响底层的具体实现。

因此，这个底层的接口，应该是由高层提出的，然后由底层实现的，也就是说底层的接口的所有权在高层模块，因此是一种所有权的倒置。

       倒置接口所有权，这就是著名的Hollywood（好莱坞）原则：不要找我们，我们会联系你。

26.2.5  接口隔离原则ISP（Interface Segregation Principle）

       所谓接口隔离原则，指的就是：不应该强迫客户依赖于他们不用的方法。

这个原则用来处理那些比较“庞大”的接口，这种接口通常会有较多的操作声明，涉及到很多的职责。客户在使用这样的接口的时候，通常会有很多它不需要的方法，这些方法对于客户来讲，就是一种接口污染，相当于强迫用户在一大堆“垃圾方法”里面去寻找他需要的方法。

因此，这样的接口应该被分离，应该按照不同的客户需要来分离成为针对客户的接口，这样的接口里面，只包含客户需要的操作声明，这样既方便了客户的使用，也可以避免因误用接口而导致的错误。

分离接口的方式，除了直接进行代码分离之外，还可以使用委托来分离接口，在能够支持多重继承的语言里面，还可以采用多重继承的方式进行分离。

26.2.6  最少知识原则（Least Knowledge Principle）

所谓最少知识原则，指的就是：只和你的朋友谈话。

这个原则用来指导我们在设计系统的时候，应该尽量减少对象之间的交互，对象只和自己的朋友谈话，也就是只和自己的朋友交互，从而松散类之间的耦合。通过松散类之间的耦合来降低类之间的相互依赖，这样在修改系统的某一个部分时候，就不会影响其它的部分，从而使得系统具有更好的可维护性。

那么究竟哪些对象才能被当作朋友呢？最少知识原则提供了一些指导：

• 当前对象本身
• 通过方法的参数传递进来的对象
• 当前对象所创建的对象
• 当前对象的实例变量所引用的对象
• 方法内所创建或实例化的对象

总之，最少知识原则要求我们的方法调用，必须保持在一定的界限范围之内，尽量减少对象的依赖关系。

26.2.7  其它原则

       除了上面提到的这些原则，还有一些大家都熟知的原则，比如：

• 面向接口编程
• 优先使用组合，而非继承

当然也还有很多大家不是很熟悉的原则，比如：

• 一个类需要的数据应该隐藏在类的内部
• 类之间应该零耦合，或者只有传导耦合，换句话说，类之间要么没有关系，要么只使用另一个类的接口提供的操作
• 在水平方向上尽可能统一的分布系统功能
• 。。。。。。等等还有很多，这里就不去详细讨论这些内容了。