23种设计模式(C++)
每一种都有对应理解的相关代码示例 → Git原码
一. GOF-23 模式分类
从目的来看
• 创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击。
• 结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。
• 行为型（Behavioral）模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。
从范围来看
• 类模式处理类与子类的静态关系。
• 对象模式处理对象间的动态关系。
二. 重构获得模式（Refactoring to Patterns）
-
面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指是那些可以满足 “应对变化，提高复用”的设计 。
-
现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
-
设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。
三. 重构关键技法
-
静态 → 动态
-
早绑定 → 晚绑定
-
继承 → 组合
-
编译时依赖 → 运行时依赖
-
紧耦合 → 松耦合
四. 从封装变化角度对模式分类
组件协作：
Template Method
Observer / Event
Strategy
单一职责：
Decorator
Bridge
对象创建:
🔗 对象创建（FactoryMethod - AbstractFactory - Prototype - Builder）
Factory Method
Abstract Factory
Prototype
Builder
对象性能：
Singleton
Flyweight
接口隔离:
Façade
Proxy
Mediator
Adapter
状态变化：
Memento
State
数据结构：
Composite
Iterator
Chain of Responsibility
行为变化：
Command
Visitor
领域问题：
Interpreter
什么时候不用模式
- 代码可读性很差时
- 需求理解还很浅时
- 变化没有显现时
- 不是系统的关键依赖点
- 项目没有复用价值时
- 项目将要发布时
经验之谈
- 不要为模式而模式
- 关注抽象类 & 接口
- 理清变化点和稳定点
- 审视依赖关系
- 要求Framework 和 Application 的区隔思维
- 良好的设计是演化的结果
设计模式成长之路
- “手中无剑，心中无剑” ： 见模式而不知
- “手中有剑，心中无剑” ：可以识别模式，作为应用开发人员模式
- “手中有剑，心中有剑” ： 作为框架开发人员为应用设计某些模式
- “手中无剑，心中有剑” ： 忘掉模式，只有原则
