设计模式的原则与策略

设计模式的原则与策略

1、开闭原则（open-closed principle, OCP）

模块、方法和类应该对扩展开放，对修改封闭。

完全遵守开闭原则几乎是不可能的，但是它可以作为一个目标，指引正确的方向。代码越遵守这一原则，以后适应新（而且可能是无法预测的）需求就越轻松。

2、依赖倒置原则（dependency inversion principle, DIP）

・高层模块不应该依赖于低层模块。高层模块和低层模块都应该依赖抽象。・抽象不应该依赖于细节。细节应该依赖于抽象。

Christopher Alexander 称此为“复杂化”——一种从最简单（概念性）的层次开始，然后逐渐添加细节和特征，随着逐步深化，设计也渐趋复杂的过程。复杂化的依赖倒置是使用设计模式的中心基础原则。

这一原则隐含着使用对象和被使用对象之间只能在概念层次存在耦合，而非实现层次，这与《设计模式》一书中所建议的应该“按接口设计”可以说是英雄所见略同。

3、里氏代换原则（LSP）

子类型必须能够替换掉它们的父类型。

一个从基类派生的类应该支持基类的所有行为。→

（只要有可能）让使用对象无法知道是否存在派生类。实践中，这意味着子类型不应该在基类型的公开接口中添加新的公开方法。这还意味着，基类型必须是所建模的概念的完整规格说明。

（这和目前所理解的子类的扩展的作用相悖，实践中可能会遇到困难，所以以前一直知道这个原则，但却放弃遵循。其实是理解得不对，看下面这个例子就知道以后应该怎么做了。

但是，“子类型不应该在基类型的公开接口中添加新的公开方法”，这一点似乎很少能做得到。）

例

问题：一个鸟类，一个企鹅类，如果鸟是可以飞的，企鹅不会飞，那么企鹅是鸟吗？企鹅可以继承鸟这个类吗？

回答：鸟会飞，企鹅不会飞，尽管在生物学分类上，企鹅是一种鸟，但在编程世界里，企鹅不能继承“鸟类”，因为企鹅不能支持“鸟类”的飞这个动作。

4、封装变化原则

不让一个类封装两个要变化的事物，除非这些变化明确地耦合在一起。

5、单一职责原则（SRP）

就一个类而言，应该仅有一个引起它变化的原因。

6、迪米特法则（LoD）（最少知识原则）

如果两个类不必彼此直接通信，那么这两个类不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private 状态，不需要让别的类知道的字段或行为就不要公开。

迪米特法其根本思想，是强调了类之间的松耦合。只有解耦后，类的复用性才能提高。

迪米特法则还有一个更简单的的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

7、合成/聚合复用原则（CARP）

尽量使用合成/聚合，尽量不要使用类继承。

好处是，优先使用对象的合成/聚合将有助于保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长到不可控制的庞然大物。