【C++设计模式】3-设计模式分类及总结（23种）

23种设计模式分类及总结

一、学习设计模式的重要方法

1 重构获得模式（Refactoring to Patterns）

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

2 推荐图书

3 重构的关键技法

静态 → 动态

早绑定 → 晚绑定

继承 → 组合

编译时依赖 → 运行时依赖

紧耦合 → 松耦合

二、GOF-23 模式分类

1 从目的看

创建型（Creational）模式（5种）

  作用：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化对对象创建时具体类型实现带来的冲击。
  分类：

• 单例模式（Singleton）
• 工厂模式（Factory）
• 抽象工厂模式（Abstract Factory）
• 构建器模式（Builder）
• 原型模式（Prototype）

结构型（Structural）模式（7种）

  作用：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化对对象的结构带来的冲击。
  分类：

• 适配器模式（Adapter）
• 桥接模式（Bridge）
• 装饰模式（Decorator）
• 组合模式（Composite）
• 外观/门面模式（Facade）
• 享元模式（Flyweight）
• 代理模式（Proxy）

行为型（Behavioral）模式（11种）

    作用：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。
  分类：

• 模板方式模式（Template Method）
• 命令模式（Command）
• 迭代器模式（Iterator）
• 观察者模式（Observer）
• 中介者模式（Mediator）
• 备忘录模式（Memento）
• 解释器模式（Interpreter）
• 状态模式（State）
• 策略模式（Strategy）
• 职责链模式（Chain of Resposibility）
• 访问者模式（Visitor）

2 从范围来看

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

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

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

1 组件协作

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

1.1 模板方法模式（Template Method）

1.2 策略模式（Strategy）

1.3 观察者/事件模式（Observer/Event）

2 单一职责

    在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。这里并不是说其他模式无职责，只不过下面这两个模式的职责问题比较突出。

2.1 装饰模式（Decorator）

2.2 桥接模式（Bridge）

3 对象创建

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

3.1 工厂模式（Factory）

3.2 抽象工厂模式（Abstract Factory）

3.3 装饰模式（Decorator）

3.4 构建器模式（Builder）

4 对象性能

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

4.1 单例模式（Singleton）

4.2 享元模式（Flyweight）

5 接口隔离

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

5.1 外观/门面模式（Facade）

5.2 代理模式（Proxy）

5.3 中介者模式（Mediator）

5.4 适配器模式（Adapter）

6 状态变化

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

6.1 备忘录模式（Memento）

6.2 状态模式（State）

7 数据结构

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

7.1 组合模式（Composite）

7.2 迭代器模式（Iterator）

7.3 职责链模式（Chain of Resposibility）

8 行为变化

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

8.1 命令模式（Command）

8.2 访问者模式（Visitor）

9 领域问题

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

9.1 解释器模式（Interpreter）