设计模式的原则和策略

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

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

1.单一职责原则

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

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

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

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

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

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

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

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

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

 

3.依赖倒置原则，dependency inversion principle，DIP

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

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

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

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

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

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

4.里低代换原则

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

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

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

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

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

6.从背景设计原则

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

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

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

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

 

8.抽象类与接口

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

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

 

9.理性怀疑原则

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

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

 

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

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

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

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

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

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

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

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

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