设计模式的原则和策略

在局部层次，模式告诉如何解决给定背景下的特定问题；

在全局层次，模式提供了一张应用程序各组件的关系图。

可总结出六大原则

1.单一职责原则

类中的职责过多时，一具职责变化可能会削弱或抑制这个类完成其它职责的能力，导致脆弱的设计。

如果能想到多于一个的动机改变这个类，则这个类就具有多于一个的职责，就应该考虑类的职责分离。

这个原则也即是强内聚，松耦合。

有且只有一个原因会引起类的变化，手不要伸太长，否则的话，相关的代码分散到系统各个地方，随着系统的扩张，维护的代码也会呈几何增长。

2.依赖倒置原则

dependency inversion principle，DIP

高层模块不应该依赖低层模块，它们都依赖抽象，即细节都依赖于抽象，总之是依赖抽象。

高层模块依赖抽象，低层模块实现抽象。

复杂化：从最简单的概念性层次开始，逐渐添加细节和特征。

复杂化和依赖倒置是使用设计模式的中心基础原则。

这一原则隐含着对象间只在概念层次存在耦合，非实现层次。这与“按接口设计”吻合，即对接口编程。

一个从基类派生的类应该支持基类的所有行为。这子类型不应该在基类型的公开接口中添加新的公开方法。基类型必须是所建模的概念的完整规格说明。

3.里氏替代原则

子类能替换掉它们的父类型。里氏替换原则建立在继承之上，在任何父类的地方都可以被替换成子类。

4.迪米特法则，最小知识原则

尽量减小两个类间的直接通信。如果它们之间需要建立调用关系，尽可能通过第三者转发调用。

迪米特法则强调在类的结构设计上，每一个类都应当尽量降低成员的访问权限。它的根本思想是强调了类之间的松耦合。

类之间的耦合越弱，越利于复用。弱耦合关系的类的修改涉及影响最小。

迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的，它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则（Least Knowledge Principle, LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。

• ① 只与直接的朋友们通信；
• ② 不要跟“陌生人”说话；
• ③ 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

只要两个对象之间有耦合关系，两个对象之间就是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，当前对象本身（this）、成员变量、以参数形式传入当前对象方法中的对象、方法返回值中的类，当前对象创建的对象为直接的朋友。类不要过多的暴露方法给外部，暴露的越多，类之间的耦合度就越高。距离产生美，过多的亲密接触（方法之间的调用）最后任何一方的改动就会影响到另外一方，就越痛苦。

5.接口隔离原则

接口隔离指的是接口职责，接口尽量少小而精。

6.开闭原则

open-closed principle，OCP：模块，方法和类应该对扩展开放，对修改封闭。

即应该将软件设计为不需要修改代码就可以扩展功能。它本质上意味着将软件设计成为，新功能能够作为单独的模式加入系统，尽量降低了集成的成本。

例如在Bridge模式中就有可能不修改已有的类，而增加新的实例，来扩展该软件。

完全遵守开闭原则几乎不可能，但可以把它作为一个目标。对一些无法封闭的变化，可以构造抽象来隔离这些变化。

然而对每个部分都可以采用抽象同样不是一个好主意，拒绝不成熟的抽象和采用适当的抽象同样重要。即过犹不及。

另外在使用给定的代码时，若需要增加新功能，也要遵循开闭原则，扩展而不要修改那些代码。比如采用包装或继承，或objective-c中的类别。

上线的产品必然是经过大量测试验证的，是一种趋于稳定的状态，如果把原来的东西修改，必然是要做大量回归测试。 开闭原则是一个抽象的概念，上述五大原则和设计模式就是就是对于开闭原则进行的实际落实的成果，而其中实现开闭原则的最核心的思想就是抽象，把一切可能的变化都抽象出来。那么不管怎么变都可以对变化进行扩展。 需求变化是永无止境的，并且是没有边界的，最重要的只需要记得不应该修改，而是创建。

6.从背景设计原则

没有哪个实现方式天生优于另一个，只会在某种情况下优于另一个。

7.封装变化原则，或者理解为封装变化时有哪些原则

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

模式还有助于找到对象之间的关系。

8.抽象类与接口

抽象类允许有公共的状态和行为，是一种聚集相关实体的方式。接口的关注点是要使用这些派生/实现的对象。

具有公共状态或行为的对象从这个抽象类派生，而不直接共享这一状态或行为的对象实现接口。

9.理性怀疑原则

概念层次的模式和模型只是真理的抽象，是经验教训的结晶，应用于真实世界必须具体问题具体分析。

模式是发现而不是发明出来的，模式实现的具体方式应该由问题的本质，约束条件，和需求等等决定。

10.共性与可变性分析 commonality and variability analysis CVA

设计模式可能不能用于所有设计之中，但是它们提供的教益是普适的。

在现有系统中增加新功能，主要成本往往不是编写新代码，而是如何将它集成到原有系统中。原因在于，很多原有系统中的各个组成部分是紧密耦合的。而导致这种耦合的原因是开发人员在弄清楚实体本身之前，就考虑实体之间的关系（考虑的不是抽象之间的关系）。

隔离变化是设计模式的理念之一。

共性有一个原则：每个共性一个问题。否则设计中就不能具有比较强的内聚。

共性分析面向概念视角和规约视角；可变性分析面向规约视角和实现视角。

CVA强调尽早关注抽象，找到最有用的抽象。设计模式关注于抽象之间的关系，对找出最重要的抽象帮助不大。

使用设计模式获得的方案是以背景方式使用模式得出的，每次应用一个模式，直到解决方案完全显露。

使用CVA是另一种形式的从背景设计：寻找共性并创建抽象；寻找变性寻找派生；看各个共性之间的关系；