设计模式总结

设计模式：

一个目标：管理变化，提高复用

有无复用的必要性

两种手段： 分解 VS 抽象

八大原则：

原则比模式更重要

重构技法：

五种技法，相通

什么时候不用设计模式

代码可读性很差时：清楚可读性差

需求理解很差时：

变化没有显现时：

不是系统的关键依赖点：

项目没有复用价值时：

项目将要发布时：

 

经验之谈

不要为模式而模式

关注抽象类&接口

理清变化点和稳定点

审视依赖关系

要有Framework 和 Application 的区隔思维

良好的设计是演化的结果，（不是一步到位，迭代重构而来）

 

创建型模式

Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。
Factory Method, Abstract Factory, Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。
如果遇到“易变类”，起初的设计通常从FactoryMethod开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（ Abstract Factory,Builder ， Prototype ）。

结构型模式

Adapter模式注重转换接口，将不吻合的接口适配对接
Bridge模式注重分离接口与其实现，支持多维度变化
Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系
Decorator模式注重稳定接口，在此前提下为对象扩展功能
Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系
Flyweight 模式注重保留接口，在内部使用共享技术对对象存储进行优化
Proxy 模式注重假借接口，增加间接层来实现灵活控制

行为型模式（1）

Template Method模式封装算法结构，支持算法子步骤变化
Strategy模式注重封装算法，支持算法的变化
State模式注重封装与状态相关的行为，支持状态的变化
Memento模式注重封装对象状态变化，支持状态保存/恢复
Mediator模式注重封装对象间的交互，支持对象交互的变化

行为型模式（2）

Chain Of Responsibility模式注重封装对象责任，支持责任的变化
Command模式注重将请求封装为对象，支持请求的变化
Iterator 模式注重封装集合对象内部结构，支持集合的变化
Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化
Observer模式注重封装对象通知，支持通信对象的变化
Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作。

设计模式应用总结：

1.设计模式建立在对象对系统变化点的基础上进行，哪里有变化点，哪里应用设计模式。

2.设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能精确定位。

3.不能为了模式而模式，设计模式是一种软件设计的软力量，而非规标准，不应夸大设计模式的作用。

---

在任何 OOPL 中都可以创造出「固定并且代表一组无限可能的行为」的抽象概念。这些抽象概念就是 abstract base classes，而那组无限可能的行为则以所有可能的 derived classes 来表现。

模块可以操作抽象概念。由于依存于固定之抽象概念，所以模块可对修改保持封闭，而又可透过创造抽象概念之 new derived classes 对模块的行为加以扩充。

Template Method和 Strategy（Policy） 是满足 OCP 的最常见手法，它们都表达了一个清晰的分离（separation）概念，将通用功能性从该功能的实现细节中分离出来。

遵循OCP 的代价是昂贵的，需要花费开发期的时间和人力来创造适当的抽象概念。这些抽象概念也增添了软件设计的复杂度，而开发人员能够承担的抽象概念数量有其极限。显然我们希望把 OCP 的应用限制在有可能发生的变更上。怎样知道哪些变更有可能发生呢？我们做适当的研究调查、提出适切的问题、运用经验与常识。最后就等变更发生！

在许多方面，OCP 是 OOD 的核心。遵循这个原则会带来 OO 技术所宣称的最大益处，亦即弹性、复用性和维护性。然而要符合此原则并非单靠使用 OOPL 就可达到，应用程序的每个部分都运用繁多的抽象化也不是个好主意。它极需仰赖开发人员只对「显示出频频改变」特性之程序部份运用抽象化解法。抗拒「草率之抽象化」和抽象化本身一样重要。

　　90年代初期－也就是OO发展的早期－我们都深深受继承的观念所吸引。有了继承，我们就可以运用差异编程（program by difference）来设计程序！也就是说给予某个 class，它所完成的事大部分都是我们用得着的，那么我们就可以建立一个subclass，并只改变我们不想要的一小部分。只要继承 class 就可以再利用程序代码！

　　到了 1995 年，继承非常遭到滥用，而且代价昂贵。Gamma, Helm, Johnson,Vlissides 甚至强调「多使用 object composition 而少使用 class inheritance」。应该可以减少 inheritance 的使用，经常以 composition 或 delegation 来取代。

　　有两个 patterns 可以归纳 inheritance 和 delegation 之间的差异：Template Method 和 Strategy。两者都可以解决从detailed context（细节化脉络/情境）中分离出generic algorithm（一般化算法）的问题，这种需求在软件设计中极为常见。是的，我们有一个用途广泛的 algorithm，为了符合DIP(依赖倒置原则(Dependency Inversion Principle))，我们想要确保这个 generic algorithm 不要倚赖 detailed implementation，而是希望 generic algorithm 和 detailed implementation 都倚赖于abstraction（抽象概念/抽象化）。

　　Template Method 让一个 generic algorithm 可以操纵（manipulate）多个可能的detailed implementations，而 Strategy 让每一个 detailed implementation 都能够被许多不同的 generic algorithms 操纵（manipulated）。

 

《Agile Software Development, Principles, Patterns, and Practices》       

 

本文内容源自 ：

• C++设计模式 Design Patterns 李建忠  课程
• 侯捷：设计模式讲义