每一种都有对应理解的相关代码示例 → Git原码

一. GOF-23 模式分类

从目的来看

• 创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击。

• 结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。

• 行为型（Behavioral）模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。

从范围来看

• 类模式处理类与子类的静态关系。

• 对象模式处理对象间的动态关系。

二. 重构获得模式（Refactoring to Patterns）

• 面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指是那些可以满足 “应对变化，提高复用”的设计 。

• 现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。

• 设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

三. 重构关键技法

• 静态 → 动态

• 早绑定 → 晚绑定

• 继承 → 组合

• 编译时依赖 → 运行时依赖

• 紧耦合 → 松耦合

四. 从封装变化角度对模式分类

组件协作：

🔗 组件协作（TemplateMethod - Observer/Event - Strategy）

Template Method

Observer / Event

Strategy

单一职责：

🔗 单一职责（Decorator - Bridge）

Decorator

Bridge

对象创建:

🔗 对象创建（FactoryMethod - AbstractFactory - Prototype - Builder）

Factory Method

Abstract Factory

Prototype

Builder

对象性能：

🔗 对象性能（Singleton - Flyweight享元）

Singleton

Flyweight

接口隔离:

🔗 接口隔离（Facade - Proxy - Mediator - Adapter）

Façade

Proxy

Mediator

Adapter

状态变化：

🔗 状态变化（Memento备忘录 - State）

Memento

State

数据结构：

🔗 数据结构（Composite - iterator - Chain of Responsibility）

Composite

Iterator

Chain of Responsibility

行为变化：

🔗 行为变化（Command - Visitor）

Command

Visitor

领域问题：

🔗 领域问题（Interpreter）

Interpreter

什么时候不用模式

1. 代码可读性很差时
2. 需求理解还很浅时
3. 变化没有显现时
4. 不是系统的关键依赖点
5. 项目没有复用价值时
6. 项目将要发布时

经验之谈

1. 不要为模式而模式
2. 关注抽象类 & 接口
3. 理清变化点和稳定点
4. 审视依赖关系
5. 要求Framework 和 Application 的区隔思维
6. 良好的设计是演化的结果

设计模式成长之路

1. “手中无剑，心中无剑” ： 见模式而不知
2. “手中有剑，心中无剑” ：可以识别模式，作为应用开发人员模式
3. “手中有剑，心中有剑” ： 作为框架开发人员为应用设计某些模式
4. “手中无剑，心中有剑” ： 忘掉模式，只有原则