GOF-23 模式分类

从目的来看：

• 创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象。从而应对需求变化为对象创建时具体类型实现引来的冲击。
• 结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。
• 行为型（Behavioral）模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。

从范围来看：

• 类模式处理类与子类的静态关系。
• 对象模式处理对象间的动态关系。

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

重构获得模式 Refactoring to Patterns

• 面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指的是那些可以满足“应对变化，提高复用”的设计。
• 现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而更好地应对需求的变化”。“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
• 设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发初中提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

推荐图书

重构关键技法

• 静态→ 动态
• 早绑定→ 晚绑定
• 继承→ 组合
• 编译时依赖→ 运行时依赖
• 紧耦合→ 松耦合

“组件协作”模式

• 现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
• 典型模式
  • Template Method
  • Observer / Event
  • Strategy

“单一职责”模式

• 在软件组织的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键就是划清责任。
• 典型模式
  • Decorator
  • Bridge

“对象创建”模式

• 通过“对象创建”模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
• 典型模式
  • Factory Method
  • Abstract Factory
  • Prototype
  • Builder

“对象性能”模式

• 面向对象很好地解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况下，面向对象所带来的成本必须谨慎处理。
• 典型模式
  • Singleton
  • Flyweight

“接口隔离”模式

• 在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题，甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
• 典型模式
  • Facade
  • Proxy
  • Adapter
  • Mediator

“状态变化”模式

• 在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案。
• 典型模式
  • State
  • Memento

“数据结构”模式

• 常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与这些特定数据结构无关的访问，是一种行之有效的解决方案。
• 典型模式
  • Composite
  • Iterator
  • Chain of Responsibility

“行为变化”模式

• 在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合 。
• 典型模型
  • Command
  • Visitor

“领域规则”模式

• 在特定领域中，某些变化虽然频率，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。
• 典型模式
  • Interpreter