C++设计模式

设计模式简介

什么是设计模式？

Christopher Alexa nder：每一个模型描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动

从面向对象谈起：

底层思维	抽象思维
向下，如果把握机器底层从微观理解对象构造	向上，如何将我们的周围世界抽象为程序代码
语言构造	面向对象
编译转换	组件封装
内存模型	设计模式
运行时机制	架构模式

深入理解面向对象：

向下：深入理解三大面向对象机制

• 封装：隐藏内部实现
• 继承：复用现有代码
• 多态：改写对象行为

向上：深刻把握面向对象机制所带来的抽象意义，理解如何使用这些机制来表达现实世界，掌握什么是”好的面向对象设计”

软件设计负责的根本原因：变化

• 客户需求的变化
• 技术平台的变化
• 开发团队的变化
• 市场环境的变化
• …

如果解决复杂性？

分解：人们面对复杂性有一个常见的做法：即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题

抽象：更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化后的对象模型

软件设计的目标：复用

面向对象设计原则

面向对象设计最大的优势在于：抵御变化

重新认识面向对象：

• 理解隔离变化：
  • 从宏观层面看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小
• 各司其职：
  • 从微观层面来看，面向对象个方法更强调各个类的”责任”
  • 由于需求变化导致的新增类型不应该影响原来类型的实现 - 是所谓各负其责
• 对象是什么？
  • 从语言实现层面来看，对象封装了代码和数据
  • 从规格层面讲，对象是一系列可被使用的公共接口
  • 从概念层面讲，对象是某种拥有责任的抽象

面向对象设计原则：

• 依赖倒置原则（DIP）
  • 高层模块（稳定）不应该依赖于底层模块（变化），二者都应该依赖于抽象（稳定）
  • 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）
• 开放封闭原则（OCP）
  • 对扩展开放，对更改封闭
  • 类模块应该是可扩展的，但是不可修改
• 单一职责原则（SRP）
  • 一个类应该仅有一个引起它变化的原因
  • 变化的方向隐含着类的责任
• Liskov替换原则（LSP）
  • 子类必须能够替换它们的基类（IS-A）
  • 继承表达类型抽象
• 接口隔离原则（ISP）
  • 不应该强迫客户程序依赖它们不用的方法
  • 接口应该小而完备
• 优先使用功能对象组合，而不是类继承
  • 类继承通常为”白箱复用”，对象组合通常为”黑箱复用”
  • 继承在某种程度上破坏了封装性，子类父类耦合度高
  • 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低
• 封装变化点
  • 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合
• 针对接口编程，而不是针对实现编程
  • 不将变量类型声明为某个特定的具体类吗，而是声明为某个接口
  • 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口
  • 减少系统各部分的依赖关系，从而实现”高内聚、松耦合”的类型设计方案

面向接口设计：产业强身的标志：接口标准化

将设计模式提升为设计经验：

• 设计习语Design Idioms：Design Idioms描述与特定编程语言相关的低层模式，技巧，惯用法
• 设计模式Design Patterns：Design Patterns主要描述的是”类与相互通信的对象之间的组织关系”，包括它们的角色、职责、协作方式等方面
• 架构模式Architectural Patterns：Architectural Patterns描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，职责，以及如何组织它们之间关系的规则

模板方法

模板分类：

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

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

• 组件协作：
  • Template Method
  • Strategy
  • Observe/Event
• 对象性能：
  • Singleton
  • Flyweight
• 数据结构
  • Composite
  • Iterator
  • Chain of Resposibility
• 单一职责：
  • Decorator
  • Bridge
• 接口隔离：
  • Facade
  • Proxy
  • Mediator
  • Adapter
• 行为变化：
  • Command
  • Visitor
• 对象创建：
  • Factory Method
  • Abstract Factory
  • Prototype
  • Builder
• 状态变化：
  • Memento
  • State
• 领域问题：
  • Interpreter

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

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

重构关键技法：

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

“组件协作”模式

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

典型模式：

• Template Method
• Strategy
• Observer/Event

Template Method 模板模式

动机：

• 在软件构件过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现

• 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？

// 不使用模版模式
class Library {	// 程序库开发人员
public:
    void Step1() {
        // ...
    }
    void Step3() {
        // ...
    }
    void Step5() {
        // ...
    }
};

class Application {	// 应用程序开发人员
public:
    bool Step2() {
        // ...
    }
    bool Step4() {
        // ...
    }
};

int main() {
    Library lib();
    Application app();
    
    lib.Step1();
    if(app.Step2()) {
        lib.Step3();
    }
    for(int i = 0; i < 4; i++) {
        app.Step4();
    }
    lib.Step5();
}

// 使用模板模式
class Library {	// 程序库开发人员
public:
    // 稳定 template methed
    void Run() {
        Step1();
        
        if (Step2()) {	// 支持变化->虚函数的多态调用
            Step3();
        }
        
        for (int i = 0; i < 4; i++) {
            Step4();	// 支持变化->虚函数的多态调用
        }
        
        Step5();
    }
    
    virtual ~Library() { }
protected:
    void Step1() {	// 稳定
        // ...
    }
    void Step3() {	// 稳定
        // ...
    }
    void Step5() {	// 稳定
        // ...
    }
    
    virtual bool Step2() = 0;	// 变化
    virtual void Step4() = 0;	// 变化
};

class Application: public Library {	// 应用程序开发人员
public:
    bool Step2() {
        // ...
    }
    void Step4() {
        // ...
    }
};

int main() {
    Library *Lib = new Application();
    Lib->Run();
    return 0;
}

《设计模式》GoF：定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method使得子类可以不改变（复用）一个算法的结构即可重定义（override重写）该算法的某些特定步骤

要点：

• Template Method模式是一种非常基础的设计模式，在面向对象系统中有着大量应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构
• 除了可以灵活应对子步骤的变化外，”不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用
• 在具体实现方面，被Template Method调用的虚方法（）现，也可以没有任何实现（抽象方法、纯虚方法）但一般将它们设置为protected方法

结构：

Strategy 策略模式

动机：

• 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。

// 不使用策略模式
enum TaxBase {
    CN_Tax;
    US_Tax;
    DE_Tax;
};

class SalesOrder {
	TaxBase tax;
public:
    double CalculateTax() {
        // ...
        if (tax == CN_Tax) {
            // CN...
        } else if (tax == US_Tax) {
            // US
        } else if (tax == DE_Tax) {
            // DE
        }
        // ...
    }
};

// 使用策略模式
class TaxStrategy {
public:
    virtual double Calculate(const Context &context) = 0;
    virtual ~TaxStrategy() { }
};

class CNTax: public TaxStrategy {
public:
    virtual double Calculate(const Context &context) {
        // CN...
    }
};

class USTax: public TaxStrategy {
public:
    virtual double Calculate(const Context &context) {
        // US...
    }
};

class DETax: public TaxStrategy {
public:
    virtual double Calculate(const Context &context) {
        // DE...
    }
};

// 扩展
class FRTax: public TaxStrategy {
public:
    virtual double Calculate(const Context &context) {
        // FR...
    }
};

class SalesOrder {
private:
    TaxStrategy *strategy;
public:
    SalesOrder(StrategyFactory *strategyFactory) {
        this->strategy = strategyFactory->NewStrategy();
    }
    ~SalesOrder() {
        delete this->strategy;
    }
    double CalculateTax() {
        // ...
        Context context();
        
        double val = strategy->Calculate(context);	// 多态调用
        // ...
    }
};

《设计模式》GoF：定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（拓展，子类化）

要点：

• Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换
• Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常需要Strategy模式
• 如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销

结构：

Observe 观察者模式

动机：

• 在软件构建过程中，我们需要为某些对象建立一种”通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化
• 使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合

// 设计一个文件分割器伪码
class MainForm : public Form {
    TextBox *txtFilePath;
    TextBox *txtFileNumber;
    
public:
	void Button1_Click() {
		string filePath = txtFilePath->getText();
		int number = atoi(txtFileNumber->getText().c_str());
		
		FileSplitter splitter(filePath, number);
        
        splitter.split();
    }
};

class FlieSplitter {
    string m_FilePath;
    int m_FileNumber;
    
public:
    FileSplitter(const string &filePath, int fileNumber) : m_FilePath(filePath), m_FileNumber(fileNumber) {
    }
    
    void split() {
        // 读取大文件
        
        // 分批次向小文件中写入
        for (int i = 0; i < m_FileNumber; i++) {
            // ... 
        }
    }
};

// 假设需要增加一个需求:添加进度条等
class IProgress {
public:
    virtual void DoProgress(float value) = 0;
    virtual ~IProgress(){}
};

class FlieSplitter {
    string m_FilePath;
    int m_FileNumber;
   
    // 添加
    // ProgressBar *m_ProgressBar;	// 具体通知控件
    List<IProgress *> m_IprogressList;	// 抽象的通知机制
    
public:
    FileSplitter(const string &filePath, int fileNumber, IProgress *iprogress) : m_FilePath(filePath), m_FileNumber(fileNumber), mIprogress(iprogress) {
    }
    
    void addIProgress(IProgress *iprogress) {
        m_IprogressList.add(iprogress);
    }
    
    void removeIProgress(IProgress *iprogress) {
        m_IprogressList.remove_back(iprogress);
    }
    
    void split() {
        // 读取大文件
        
        // 分批次向小文件中写入
        for (int i = 0; i < m_FileNumber; i++) {
            // ... 
            float progressValue = m_FileNumber;
            progressValue = (i + 1) / progressValue;
            onProgress(progressValue);
        }
    }
protected:
    void onProgress(float value) {
        List<IProgress *>::iterator it = m_IprogressList.begin();
        // ... 
        // 针对每一个list内的元素
        while (it != m_IprogressList.end()){
            (*it)->DoProgress(progressValue);	// 更新进度条
            it++;
        }
    }
};

class MainForm : public Form, public IProgress {	// C++不推荐多继承,但是C++推荐使用一个主继承类+多个接口
    TextBox *txtFilePath;
    TextBox *txtFileNumber;
    
    // 添加进度条
    ProgressBar *progressBar;
public:
	void Button1_Click() {
		string filePath = txtFilePath->getText();
		int number = atoi(txtFileNumber->getText().c_str());
		
		ConsoleNotifier cn;
		
		// 添加progressBar
		FileSplitter splitter(filePath, number);
		// 添加两个观察者
		splitter.addIProgress(this);
        splitter.addIProgress(&cn);
        
        splitter.split();
    }
    
    virtual void DoProgress(float value) {
        progressBar->setValue(value);
    }
};	// 观察者1

class ConsoleNotifier : public IProgress {
public:
    virtual void DoProgress(float value) {
       	cout << ".";
    }
};	// 观察者2

《设计模式》GoF：定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都得到通知并自动更新

要点：

• 使用面向对象的抽象，Observe模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合
• 目标发生通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播
• 观察者自己决定是否需要订阅通知，目标对象对此一无所知
• Observe模式是基于事件的UI框架非常常用的设计模式，也是MVC模式的一个重要组成部分

结构：

“单一职责”模式

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

典型模式：

• Decorator
• Bridge

Decorator 装饰模式

动机：

• 在某些情况下，我们可能会”过度使用集成来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀
• 如何使”对象功能的扩展”能够根据需要来实现动态实现？同时避免”扩展功能的增多”带来的子类膨胀问题？从而使得任何”功能扩展变化”所导致的影响降为最低？

// 不使用装饰模式
// 业务操作
class Stream {
public:
	virtual char Read(int number) = 0;
	virtual void Seek(int position) = 0;
	virtual void Write(char data) = 0;
    
	virtual ~Stream(){}
};

// 主体类
class FileStream: public Stream {
public:
	virtual char Read(int number) {
      	// 读文件流
    }
	virtual void Seek(int position) {
      	// 定位文件流
    }
  	virtual void Write(char data) {
        // 写文件流
    } 
};

class NetworkStream: public Stream {
public:
    virtual char Read(int number) {
        // 读网络流
    }
	virtual void Seek(int position) {
      	// 定位网络流
    }
  	virtual void Write(char data) {
        // 写网络流
    } 
};

class MemoryStream: public Stream {
public:
    virtual char Read(int number) {
        // 读内存流
    }
	virtual void Seek(int position) {
      	// 定位内存流
    }
  	virtual void Write(char data) {
        // 写内存流
    } 
};

// 扩展操作
class CryptoFileStream: public FileStream {
public:
    virtual char Read(int number) {
        // 额外的加密操作...
        FileStream::Read(number);	// 读文件流
    }
    virtual void Seek(int position) {
        // 额外的加密操作...
        FileStream::Seek(position);	// 定位文件流
        // 额外的加密操作...
    }
    virtual void Write(char data) {
        // 额外的加密操作...
        FileStream::Write(data);	// 写文件流
        // 额外的加密操作...
    }
};

class CryptoNetworkStream: public NetworkStream {
public:
    virtual char Read(int number) {
        // 额外的加密操作...
        NetworkStream::Read(number);	// 读网络流
    }
    virtual void Seek(int position) {
        // 额外的加密操作...
        NetworkStream::Seek(position);	// 定位网络流
        // 额外的加密操作...
    }
    virtual void Write(char data) {
        // 额外的加密操作...
        NetworkStream::Write(data);	// 写网络流
        // 额外的加密操作...
    }
};

class CryptoNetworkStream: public MemoryStream {
public:
    virtual char Read(int number) {
        // 额外的加密操作...
        MemoryStream::Read(number);	// 读内存流
    }
    virtual void Seek(int position) {
        // 额外的加密操作...
        MemoryStream::Seek(position);	// 定位内存流
        // 额外的加密操作...
    }
    virtual void Write(char data) {
        // 额外的加密操作...
        MemoryStream::Write(data);	// 写内存流
        // 额外的加密操作...
    }
};

class BufferedFileStream: public FileStream {
    // ...
};
class BufferedFileStream: public NetworkStream {
    // ...
};
class BufferedFileStream: public MemoryStream {
    // ...
};

// 使用装饰模式
// 业务操作
class Stream {
public:
	virtual char Read(int number) = 0;
	virtual void Seek(int position) = 0;
	virtual void Write(char data) = 0;
    
	virtual ~Stream(){}
};

// 主体类
class FileStream: public Stream {
public:
	virtual char Read(int number) {
      	// 读文件流
    }
	virtual void Seek(int position) {
      	// 定位文件流
    }
  	virtual void Write(char data) {
        // 写文件流
    } 
};

class NetworkStream: public Stream {
public:
    virtual char Read(int number) {
        // 读网络流
    }
	virtual void Seek(int position) {
      	// 定位网络流
    }
  	virtual void Write(char data) {
        // 写网络流
    } 
};

class MemoryStream: public Stream {
public:
    virtual char Read(int number) {
        // 读内存流
    }
	virtual void Seek(int position) {
      	// 定位内存流
    }
  	virtual void Write(char data) {
        // 写内存流
    } 
};

// 扩展操作
DecoratorStream: public Stream {
protected:
    Stream *stream;	// ...
    DecoratorSteam(Stream *stm):stream(stm){
        
    }
};

class CryptoStream: public DecoratorStream {
public:
    CryptoStream(Stream *stm):DecoratorSteam(stm){
        
    }
    virtual char Read(int number) {
        // 额外的加密操作...
        stream->Read(number);
    }
    virtual void Seek(int position) {
        // 额外的加密操作...
        stream->Seek(position);
        // 额外的加密操作...
    }
    virtual void Write(char data) {
        // 额外的加密操作...
        stream->Write(data);
        // 额外的加密操作...
    }
};

class BufferedStream: public DecoratorStream {
public:
    BufferedStream(Stream *stm):DecoratorSteam(stm){
        
    }
    virtual char Read(int number) {
        // 额外的Buffered操作...
        stream->Read(number);
    }
    virtual void Seek(int position) {
        // 额外的Buffered操作...
        stream->Seek(position);
        // 额外的Buffered操作...
    }
    virtual void Write(char data) {
        // 额外的Buffered操作...
        stream->Write(data);
        // 额外的Buffered操作...
    }
};

void Process() {
    // 运行时装配
    FileStream *s1 = new FileStream();
    CryptoStream *s2 = new CryptoStream(s1);
    BufferedStream *s3 = new BufferedStream(s1);
}

《设计模式》GoF：动态（组合）地给一个对象增加一些额外的指责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）

要点：

• 通过采用组合而非继承的手法， Decorator模式实现了在运动时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的”灵活性差”和”多子类衍生问题”
• Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类
• Decorator模式的目的并非解决”多子类衍生的多继承”问题，Decorator模式应用的要点在于解决”主体类在多个方向上的扩展功能”——是为”装饰”的含义

结构：

Bridge 桥模式

动机：

• 由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个维度的变化
• 如何应对这种”多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度

// 不使用桥模式
class Messager {
public:
    virtual void Login(string username, string password) = 0;
    virtual void SendMessage(string message) = 0;
    virtual void SendPicture(Image image) = 0;
    
    virtual void PlaySound() = 0;
    virtual void DrawShape() = 0;
    virtual void WriteText() = 0;
    virtual void Connect() = 0;
    
    virtual void ~Messager() {} 
};

// 平台实现
class PCMessagerBase: public Message {
public:
    virtual void PlaySound() {
        // ...
    }
    virtual void DrawShape() {
        // ...
    }
    virtual void WriteText() {
        // ...
    }
    virtual void Connect() {
        // ...
    }
};

class MobileMessagerBase: public Message {
public:
    virtual void PlaySound() {
        // ***
    }
    virtual void DrawShape() {
        // ***
    }
    virtual void WriteText() {
        // ***
    }
    virtual void Connect() {
        // ***
    }
};

// 业务抽象
class PCMessagerLite: public PCMessagerBase {
public:
    virtual void Login(string username, string password) {
        PCMessagerBase::Connect();
        // ...
    }
    virtual void SendMessage(string message) {
        PCMessagerBase::WriteText();
        // ...
    }
    virtual void SendPicture(Image image) {
        PCMessagerBase::DrawShape();
        // ...
    }
};

class PCMessagerPerfect: public PCMessagerBase {
public:
    virtual void Login(string username, string password) {
        PCMessagerBase::PlaySound();
		// ...
        PCMessagerBase::Connect();
        // ...
    }
    virtual void SendMessage(string message) {
        PCMessagerBase::PlaySound();
		// ...
        PCMessagerBase::WriteText();
        // ...
    }
    virtual void SendPicture(Image image) {
        PCMessagerBase::PlaySound();
		// ...
        PCMessagerBase::DrawShape();
        // ...
    }
};

class MobileMessagerLite: public MobileMessagerBase {
	// ...
};

class MobileMessagerPerfect: public MobileMessagerBase {
	// ...
};

void Process() {
    // 编译时装配
    Messager *m = new MobileMessagerPerfect();
}

// 使用桥模式
class Messager {
protected:
	MessageImp *messagerImp;	// PCMessagerBase、MobileMessagerBase  
public:
    virtual void Login(string username, string password) = 0;
    virtual void SendMessage(string message) = 0;
    virtual void SendPicture(Image image) = 0;
    
    virtual void ~Messager() {} 
};

class MessagerImp {
public:
    virtual void PlaySound() = 0;
    virtual void DrawShape() = 0;
    virtual void WriteText() = 0;
    virtual void Connect() = 0;
    
    virtual void ~MessagerImp() {} 
};

// 平台实现
class PCMessagerImp: public MessageImp {
public:
    virtual void PlaySound() {
        // ...
    }
    virtual void DrawShape() {
        // ...
    }
    virtual void WriteText() {
        // ...
    }
    virtual void Connect() {
        // ...
    }
};

class MobileMessagerImp: public MessageImp {
public:
    virtual void PlaySound() {
        // ***
    }
    virtual void DrawShape() {
        // ***
    }
    virtual void WriteText() {
        // ***
    }
    virtual void Connect() {
        // ***
    }
};

// 业务抽象
class MessagerLite: public Message {
public:
    virtual void Login(string username, string password) {
        messagerImp->Connect();
        // ...
    }
    virtual void SendMessage(string message) {
        messagerImp->WriteText();
        // ...
    }
    virtual void SendPicture(Image image) {
        messagerImp->DrawShape();
        // ...
    }
};

class MessagerPerfect: public Message {
public:
    virtual void Login(string username, string password) {
        messagerImp->PlaySound();
		// ...
        messagerImp->Connect();
        // ...
    }
    virtual void SendMessage(string message) {
        messagerImp->PlaySound();
		// ...
        messagerImp->WriteText();
        // ...
    }
    virtual void SendPicture(Image image) {
        messagerImp->PlaySound();
		// ...
        messagerImp->DrawShape();
        // ...
    }
};

void Process() {
    // 运行时装配
    MessagerImp *mImp = new PCMessagerImp();
    Messager *m = new Messager(mImp);
}

《设计模式》GoF：将抽象部分（业务功能）与现实部分（平台实现）分离，使它们都可以独立地变化

要点总结：

• Bridge模式使用”对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度的变化，即”子类化”它们
• Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法
• Bridge模式的应用一般在”两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式

结构：

“对象创建”模式

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

典型模式：

• Factory Method
• Abstract Factory
• Prototype
• Builder

Factory Method 工厂模式

动机：

• 在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化
• 如何应对这种变换？如何绕过常规的对象创建方法（new），提供一种”封装机制”来避免客户程序和这种”具体对象创建工作”的紧耦合？

// 使用工厂模式
// SplitterFactory
class ISplitter {
public:
    virtual void split() = 0;
    virtual ~ISplitter(){}
};	// 抽象类
class SplitterFactory {
public:
    virtual ISplitter *CreateSplitter() = 0;
    virtual ~SplitterFactory(){}
};	// 工厂基类

// MainForm
class MainForm: public From {
    SplitterFactory *factory;	// 工厂
public:
    MainForm(SplitterFactory *factory) {
        this->factory = factory;
    }
    void Button1_Click() {
        ISplitter *splitter = factory->CreateSplitter();	// 多态
        splitter->split();
    }
};

// FileSplitter
class BinarySplitter: public ISplitter {
};	// 具体类
class TxtSplitter: public ISplitter {
};
class PictureSplitter: public ISplitter {
};
class VideoSplitter: public ISplitter {
};
class BinarySplitterFactory: public SplitterFactory {
public:
    virtual ISplitter *CreateSplitter() {
        return new BinarySplitter();
    }
};	// 具体工厂
class TxtSplitterFactory: public SplitterFactory {
public:
    virtual ISplitter *CreateSplitter() {
        return new TxtSplitter();
    }
};
class PictureSplitterFactory: public SplitterFactory {
public:
    virtual ISplitter *CreateSplitter() {
        return new PictureSplitter();
    }
};
class VideoSplitterFactory: public SplitterFactory {
public:
    virtual ISplitter *CreateSplitter() {
        return new VideoSplitter();
    }
};

《设计模式》GoF：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦；手段：虚函数）到子类

要点：

• Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱
• Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非改变）的策略，较好地解决了这种紧耦合关系
• Factory Method模式解决”单个对象”的需求变化。缺点在于要求创建方法/参数相同

Abstract Factory 抽象工厂

动机：

• 在软件系统中，经常面临着”一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作
• 如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种”封装机制”来避免客户程序和这种”多系列具体对象创建工作”的紧耦合？

// 未使用抽象工厂
class EmplyeeDAO {
public:
    vector<EmployeeDAO> GetEmployees() {
        // 已经new了一个固定对象,在后期如果更换数据库类型变化繁琐
        SqlConnection* connection = new SqlConnection();
        connection->ConnectionString = "...";
        
        SqlCommand * command = new SqlCommand();
        command->CommandText = "...";
        command->SetConnection(connection);	// 关联性
        
        SqlDataReader *reader = command->ExecuteReader();
        while (reader->Read()) {
        }
    }
};

// 使用抽象工厂
// 数据库访问有关的基类
class IDBConnection {
    
};
class IDBCommand {
    
};
class IDataReader {
    
};
// IDB工厂,三个工厂具有相关性我么可以将其放在一起
class IDBFactory {
public:
    virtual IDBConnection *CreateDBConnect() = 0;
    virtual IDBCommand *CreateDBCommand() = 0;
    virtual IDataReader *CreateDataReader() = 0;
};

// 支持SQL Server
class SqlConnection: public IDBConnection {
};
class SqlCommand: public IDBCommand {
};
class SqlDataReader: public IDataReader {
};
// 抽象工厂
class SqlDBFactory: public IDBFactory {

};

// 支持Oracle
class OracleConnection: public IDBConnection {
};
class OracleCommand: public IDBCommand {
};
class OracleDataReader: public IDataReader {
};

// ...
class EmplyeeDAO {
    IDBFactory *dbFactory;
public:
    vector<EmployeeDAO> GetEmployees() {
        SqlConnection* connection = dbFactory->CreateDBConnection();
        connection->ConnectionString = "...";

        SqlCommand * command = dbFactory->CreateDBCommand();
        command->CommandText = "...";
        command->SetConnection(connection);	// 关联性

        SqlDataReader *reader = command->ExecuteReader();
        while (reader->Read()) {
        }
    }
};

《设计模式》GoF：提供一个接口，让该接口负责创建一系列”相关或者相互依赖的对象”，无需指定它们具体的类

要点：

• 如果没有应对”多系列对象构建”的需求变化，则没有必要使用Abstact Factory模式，这时候使用简单的工厂完全可以
• “系列对象”指的是在某一特定系列下的对象之间有相互依赖或作用的关系。不同系列的对象之间不能相互依赖
• Abstract Factory模式主要在于应对”新系列”的需求变动。其缺点在于难以应对”新对象”的需求变动

结构：

Prototype 原型模式

动机：

• 在软件系统中，经常面临着”某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口
• 如何应对这种变化？如何向”客户程序（使用这些对象的程序）”隔离出”这些易变对象”，从而使得”依赖这些易变对象的客户程序”不随则会需求的改变而改变

// 使用原型模式...提取工厂模式伪代码
class ISplitter {	// 抽象类
public:
	virtual void split() = 0;
    virtual ISplitter *clone() = 0;		// 通过克隆自己创建对象
    
    virtual ~ISplitter(){}
};

// MainForm
class MainForm: public From {
    ISplitter *prototype;	// 工厂
public:
    MainForm(ISplitter *prototype) {
        this->prototype = prototype;
    }
    void Button1_Click() {
        ISplitter *splitter = prototype->clone();	// 克隆原型
        splitter->split();
    }
};

// FileSplitter
class BinarySplitter: public ISplitter {
public:
    ISplitter *clone() {
        return new BinarySplitter(*this);
    }
    
    virtual void split() {
        // ...
    }
};	// 具体类
class TxtSplitter: public ISplitter {
public:
    ISplitter *clone() {
        return new TxtSplitter(*this);
    }
};
class PictureSplitter: public ISplitter {
public:
    ISplitter *clone() {
        return new PictureSplitter(*this);
    }
};
class VideoSplitter: public ISplitter {
public:
    ISplitter *clone() {
        return new VideoSplitter(*this);
    }
};

《设计模式》GoF：使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象

要点：

• Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些”易变类”拥有”稳定的接口”
• Prototype模式对于”如何创建易变类的实体对象”采用”原型克隆”的方法来做，它使得我们可以非常灵活地动态创建”拥有某些稳定接口”——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone
• Prototype模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝

结构：

Builder 构建器

动机：

• 在软件系统中，有时候面临着”一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象各部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定
• 如何应对这种变化？如何提供一种”封装机制”来隔离出”复杂对象的各个部分”的变化，从而保持系统中的”稳定构建算法”不随着需求改变而改变？

// 使用构建器模式
// 将对象的表示和构建分离
class House {
    // ...
};

class HouseBuilder {
public:
    House *GetResult() {
        return pHouse;
    }
    
    virtual ~HouseBuilder(){}
    
protected:
    virtual void BuildPart1() = 0;
    virtual void BuildPart2() = 0;
    virtual void BuildPart3() = 0;
    virtual void BuildPart4() = 0;
    virtual void BuildPart5() = 0;
    
    House *pHouse;
};

class StoneHouse: public House {
};
class StoneHouseBuilder: public HouseBuilder {

protected:
    virtual void BuildPart1() {
        // pHouse->Part1 = ...;
    }
    virtual void BuildPart2() {
        
    }
    virtual void BuildPart3() {
        
    }
    virtual void BuildPart4() {
        
    }
    virtual void BuildPart5() {
        
    }
};

class HouseDirector {
public:
    HouseBuilder *pHouseBuilder;
    // 构造器
    HouseDircetor(HouseBuilder *pHouseBuilder) {
        this->pHouseBuilder = pHouseBuilder;
    }
    
    House *Construct() {
        pHouseBuilder->BuildPart1();
        // C++中如果构造函数是虚函数的话,其使用的是静态绑定,所以这个额函数不能写成构造函数,只能写为自己声明的函数init
        
        for (int i = 0; i < 4; i++) {
            pHouseBuilder->BuildPart2();
        }
        
        bool flasg = pHouseBuilder->BuildPart3();
        
        if (flag) {
            pHouseBuilder->BuildPart4();
        }
        
        pHouseBuilder->BuildPart5();
        
        return pHouseBuilder->GetResult();
    }
};

《设计模式》GoF：将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）

要点：

• Builder模式主要用于”分步骤构建一个复杂的对象”。在这其中”分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化
• 变化点在哪里，封装哪里——Builder模式主要应对”复杂对象各个部分”的频繁需求变动。其缺点在于难以应对”分步骤构建算法”的需求变动
• 在Builder模式中，要注意不同语言中构造器内调用虚函数的差别（C++ vs. C#）

结构：

“对象性能”模式

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

典型模式：

• Singleton
• Flyweight

Singleton 单件模式

动机：

• 在软件系统中，经常有这样一些特殊的类，必须保证他们在系统中只存在一个实例，才能保证它们的逻辑正确性、以及良好的效率
• 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例
• 这应该是类设计者的责任，而不是使用者的责任

// 不使用单件模式
class Singleton {
private:
	Singleton();
    Singleton(const Singleton &other);
public:
    static Singleton *getInstance();
    static Singleton *m_instance;
};

Singleton *Singleton::m_instance = nullptr;

// 线程非安全版本(多线程环境下)
Singleton *Singleton::getInstance() {
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    
    return m_instance;
};

// 线程安全版本, 但锁的代价过高
Singleton *Singleton::getInstance() {
    Lock lock;	// 锁会在函数结束时候
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

// 双检查锁, 但由于内存读写reorder不安全
Singleton *Singleton::getInstance() {
    if (m_instance == nullptr) {	// 降低代价
        Lock lock;
        if (m_instance == nullptr) {
        	m_instance = new Singleton();
    	}
    }
    return m_instance;
}

// C++11版本之后的跨平台实现(volatile)
std::atomic<Singleton *>Singleton::m_instance;
std::mutex Singleton::m_mutex;

Singleton *Singleton::getInstance() {
    Singleton *tmp = m_instance.load(std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_acquire);	// 获取内存fence
    if (tmp == nullptr) {
        std::lock_guard<std::mutex> lock(m_mutex);
        tmp = m_instance.load(std::memory_order_relaxed);
        if (tmp == nullptr) {
            tmp = new Singleton;
            std::atomic_thread_fence(std::memory_order_release);	// 释放内存fence
            m_instance.store(tmp, std::memory_order_relaxed);
        }
    }
    
    return tmp;
}

《设计模式》GoF：保证一个类仅有一个实例，并提供一个该实例的全局访问点

要点：

• Singleton模式中的实例构造器可以设置为protected以允许子类派生
• Singleton模式一般不要支持拷贝构造函和Clone接口，因为这有可能导致多个对象实例，与Singleton模式初衷违背
• 如何实现多线程环境下安全的Singleton？注意对双检查锁的正确实现

结构：

Flyweight 享元模式

动机：

• 在软件系统中春纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价
• 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来操作

// 使用享元模式
class Font {
private:
    // unique object key
    string key;
    // object state
    // ...
public:
    Font(const string &ket) {
        // ...
    }
};

class FontFactory {
private:
    map<string, Font *> fontPool;
public:
    Font *GetFont(const string &key) {
        map<string, Font *>::iterator item = fontPool.find(key);
        if (item != fontPool.end()) {	// 判断在map容器中是否存在key类型的font
            return fontPool[key];
        } else {
            Font *font = new Font(key);
            fontPool[key] = font;
            return font;
        }
    }
    
    void clear() {
        // ...
    }
};

《设计模式》GoF：运用共享技术有效地支持大量细粒度的对象

要点：

• 面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题
• Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理
• 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断

结构：

“接口隔离”模式

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

典型模式：

• Facade
• Proxy
• Adapter
• Mediator

Facade 门面模式

动机：

• 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这职工过多的耦合面临很多变化的挑战
• 如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖关系相互解耦？

《设计模式》GoF：为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口是的这一子系统更加容易使用（复用）

要点：

• 从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种”解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化
• Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构模式
• Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是”相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合

结构：

Proxy 代理模式

动机：

• 在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦
• 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式

class ISubject {
public:
    virtual void process();
};

class RealSubject: public ISubject {	// 不使用Proxy
public:
    virtual void process() {
        // ...
    }
};

class ProxySubject: public ISubject {	// 使用Proxy
public:
    virtual void process() {
        // 对RealSubject间接访问
    }
};

class ClientApp {
    ISubject *subject;
public:
    ClientApp() {
        // subject = new RealSubject();	// 在某些情况下较为复杂
        subject = new ProxySubject();
    }
    
    void DoTask() {
        // ...
        subject->process();
        // ...
    }
};

《模式定义》GoF：为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问

要点：

• “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的Proxy对象便是解决这一问题的非常手段
• 具体Proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-writer技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做Proxy
• Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的

结构：

Adapter 适配器

动机：

• 在软件系统中，由于应用环境的变化，常常需要将”一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的
• 如何应对这种”迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

// 使用适配器
class ITarget {	// 目标接口(新接口)
public:
    virtual void process() = 0;
};

class IAdaptee {	// 遗留接口(老接口)
public:
    virtual void foo(int data) = 0;
    virtual int bar() = 0;
};

class OldClass: public IAdaptee {	// 遗留类型
    // ...
};

class Adapter: public ITarget {
protected:
    IAdaptee *pAdaptee;	// 组合了一个对象,称为对象适配器
public:
    Adapter(IAdaptee *pAdaptee) {
        this->pAdaptee = pAdaptee;
    }
    
    virtual void process() {
        int data = pAdaptee->bar();
        pAdaptee->foo(data);
    }
};

int main() {
    IAdaptee *pAdaptee = new OldCladd();
    
    ITarget *pTarget = new Adapter(pAdaptee);
    pTarget->process();
}

《设计模式》GoF：将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

要点：

• Adapter模式主要应用于”希望复用一些现存的类，但是接口又与复用环境不一致的情况”，在遗留代码复用、类库迁移等方面非常有用
• GoF23定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用”多继承”的实现方式，一般不推荐使用。对象适配器采用”对象组合”的方式，跟符合松耦合精神
• Adapter模式可以实现的非常灵活，不必拘泥于GoF23中定义的两种结构。例如，完全可以将Adapter模式中的”现存对象”作为新的接口方法参数，来到达适配器的目的

结构：

Mediator 中介者

动机：

• 在软件构建过程中，经常会出现多个对象相互关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的应用关系面临不断地变化
• 在这种情况下，我们可使用一个”中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化

《设计模式》GoF：用一个中介对象来封装（封装变化）一系列的对象交互。中介者使用对象不需要显式地相互引用（编译时依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互

要点：

• 将多个对象间负责的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变”多个对象相互管理”为”多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化
• 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理
• Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系

结构：

“状态变化”模式

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

典型模式：

• State
• Memento

State 状态模式

动机：

• 在软件构建过程中，某些对象的状态如果改变，其行为也会随之发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同
• 如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？

// 不使用状态模式
enum NetworkState {
    Network_Open,
    Network_Close,
    Network_Connect,
};

class NetworkProcessor {
    NetworkState state;
public:
    void Operation1() {
        if (state == Network_Open) {
            // ...
            state = Network_Close;
        } else if (state == Network_Close) {
            // ...
            state = Network_Connect;
        } else if (state == Network_Connect) {
            // ...
            state = Network_Open;
        }
    }
    
    void Operation2() {
        if (state == Network_Open) {
            // ...
            state = Network_Connect;
        } else if (state == Network_Close) {
            // ...
            state = Network_Open;
        } else if (state == Network_Connect) {
            // ...
            state = Network_Close;
        }
    }
};

// 使用状态模式
class NetworkState {
public:
    NetworkState *pNext;	// 状态对象指针
    virtual void Operation1() = 0;
    virtual void Operation2() = 0;
    virtual void Operation3() = 0;
    
    virtual ~NetworkState(){}
};

class OpenState: public NetworkState {
    static NetworkState *m_instance;
public:
    static NetworkState *getInstance() {
        if (m_instance = nullptr) {
            m_instance = new OpenState();
        }
        return m_instance;
    }
    
    void Operation1() {
        // ...
        pNext = CloseState::getInstance();
    }
    void Operation2() {
        // ...
        pNext = ConnectState::getInstance();
    }
    void Operation3() {
        // ...
        pNext = OpenState::getInstance();
    }
};

class CloseState: public NetworkState {
    
};
// ...扩展子类

class NetworkProcessor {
    NetworkState *pState;
public:
    NetworkProcessor(NetworkState *pState) {
        this->pState = pState;
    }
    
    void Operation1() {
        // ...
        pState->Operation1();
        pState = pState->pNext;
        // ...
    }
    
    void Operation2() {
        // ...
        pState->Operation2();
        pState = pState->pNext;
        // ...
    }
    
    void Operation3() {
        // ...
        pState->Operation3();
        pState = pState->pNext;
        // ...
    }
};

《设计模式》GoF：允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为

要点：

• State模式将所以与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦
• 为不同的状态引入了不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换
• 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销

结构：

Memento 备忘录

动机：

• 在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到的状态，便会暴露对象的细节实现
• 如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性

class Memento {
    string state;
public:
    Memento(const string &s) : state(s){}
    string getState() const {
        return state;
    }
    void setState(const string &s) {
        state = s;
    }
};

class Originator {
    string state;
    // ...
public:
    Originator() {}
    Memento createMomento() {
        Memento m(state);	// 在不同情况下实现不同且较为复杂
        return m;
    }
    void setMomento(const Memento &m) {
        state = m.getState();
    }
};

int main() {
    Originator orginator;
    
    // 存储到备忘录
    Memento mem = orginator.createMomento();
    
    // ... 改变orginator状态
    
    // 从备忘录中恢复
    orginator.setMemento(memento);
}

《设计模式》GoF：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态

要点：

• 备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原发器状态
• Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但同时又需要将状态保持到外界（Memento）
• 由于现代语言运行时（如C#、Java等）都具有相当的对象序列化支持，因此往往采用效率较高、又较容易正确实现的序列化方案来实现Memento模式

结构：

“数据结构”模式

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

典型模式：

• Composite
• Iterator
• Chain of Resposibility

Composite 组合模式

动机：

• 在软件某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象结构）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端
• 如何将”客户代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？

class Component {
public:
    virtual void process() = 0;
    virtual ~Component(){}
};

class Composite: public Component {
    string name;
    list<Component *> elements;	// 可能是Composite或Leaf
public:
    Composite(const string &s) : name(s) {}
    void add(Comonent *element) {
        elements.push_back(element);
    }
    
    void remove(Comonent *element) {
        elements.remove(element);
    }
    
    void process() {
        // process cuttent node
        // process leaf nodes
        for (auto &e : elements) {
            e->process();	// 多态调用
        }
    }
};

class Leaf: public Component {
    string name;
public:
    Leaf(string s) : name(s) {}
    void process() {
        // process current node
    }
};

void Invoke(Component &c) {
    // ...
    c.process();
    // ...
}

int main() {
    Composite root("root");
    Composite treeNode1("treeNode1");
    Composite treeNode2("treeNode2");
    Composite treeNode3("treeNode3");
    Composite treeNode4("treeNode4");
    Leaf leaf1("leaf1");
    Leaf leaf2("leaf2");
    
    root.add(&treeNode1);
    treeNode1.add(&treeNode2);
    treeNode2.add(&leaf1);
    
    root.add(&treeNode3);
    treeNode3.add(&treeNode4);
    treeNode4.add(&leaf2);
    
    process(root);
    process(leaf2);
    process(treeNode3);
}

《设计模式》GoF：将对象组合成树形结构以表示”部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性（稳定）

要点：

• Composite模式采用树形结构来实现普遍存在的对象容器，从而将”一对多”的关系转化为”一对一”的关系，使得客户代码可以一致地（复用）处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器
• 将”客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的接口——而非对象容器内部实现结构——发生依赖，从而更能”应对变化”
• Composite模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率

结构：

Iterator 迭代器

在C++语言中已经过时

动机：

• 在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明的访问其中包含的元素；同时这种”透明遍历”也为”同一种算法在多种集合对象上操作”提供了可能
• 使用面向对象技术将这种遍历机制抽象为”迭代器对象”为”应对变化中的集合对象”提供一种优雅的方式

template<typename T>
class Iterator {
public:
    virtual void first() = 0;
    virtual void next() = 0;
    virtual bool isDone() const = 0;
    virtual T& current() = 0;
};

template<typename T>
class MyCollection {
public:
    Iterator<T> GetIterator() {
        // ...
    }
};

template<typename T>
class CollectionIterator: public Iterator<T> {
    MyCollection<T> mc;
public:
    CollectionIterator(const MyCollection<T> &c): mc(c) {}
    
    void first() override {
        
    }
    
    void next() override {
        
    }
    
    bool isDone() const override {
        
    }
    
    T& current() override {
        
    }
};

void MyAlgorithm() {
    MyCollection<int> mc;
    
    Iterator<int> iter = mc.GetIterator();
    
    for (iter.first(); !iter.isDone(); iter.next()){
        cout << iter.current() << endl;
    }
}

《设计模式》GoF：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露（稳定）该对象的内部表示

要点：

• 迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示
• 迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作
• 迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题

结构：

Chain of Responsibility 职责链

动机：

• 在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少带来请求发送者与接受者的紧耦合
• 如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定处理请求，从而使两者解耦

《设计模式》GoF：使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止

要点：

• Chain of Responsibility模式的应用场合在于”一个请求可能有多个接受者，但是最后真正的接受者只有一个”，这时候请求发送者与接受者的耦合有可能出现”变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好的应对变化
• 应用了Chain of Responsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责
• 如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任

结构：

“行为变化”模式

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

典型模式：

• Command
• Visitor

Command 命令模式

动机：

• 在软件构建过程中，”行为请求者”与”行为实行者”通常呈现一种”紧耦合”。但在某些场合——比如需要对行为进行”记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的
• 在这种情况下，如何将”行为请求者”与”行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合

class Command {
public:
	virtual void execute() = 0;
};

class ConcreteCommand1: public Command {
	string arg;
public:
    ConcreteCommand1(const string &a) : arg(a) {}
    void execute() override {
        cout << "#1 precess ..." << arg << endl;
    }
};

class ConcreteCommand2: public Command {
	string arg;
public:
    ConcreteCommand2(const string &a) : arg(a) {}
    void execute() override {
        cout << "#2 precess ..." << arg << endl;
    }
};

class MacroCommand: public Command {
    vector<Command *> conmmands;
public:
    void addCommand(Command *c) {
        conmmands.push_back(c);
    }
    
    void execute() override {
        for (auto &c : commands) {
            c->execute();
        }
    }
};

int main() {
    ConcreteCommand1 command1(receiver, "Arg ###");
    ConcreteCommand2 command2(receiver, "Arg $$$");
    
    MacroCommand macro;
    macro.addCommand(&command1);
    macro.addCommand(&command2);
    
    macro.execute();
}

《设计模式》GoF：将一个请求（行为）封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作

要点：

• Command模式的根本目的在于将”行为请求者”与”行为实现者”解耦，在面向对象语言中，常见的实现手段是”将行为抽象为对象”
• 实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个”命令”封装为一个”复合命令”MacroCommand
• Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的”接口-实现”来定义行为接口规范，更严格，但有性能损失；C++函数对象以函数签名来定义行为接口规范，更灵活，性能更高

结构：

Vistior 访问器

动机：

• 在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计
• 如果在不更改层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？

// 不使用访问器模式
class Element {
public:
    virtual void Func1() = 0;
    // virtual void Func2() = 0;增加方法2违背了开闭原则
    
    virtual ~Element(){}
};

class ElementA: public Element {
public:
    void Func1() override {
        // ...
    }
   	// 实现方法2
};

class ElementB: public Element {
public:
    void Func1() override {
        // ...
    }
    // 实现方法2
};

// 使用访问器模式
class Visitor;

class Element {
public:
    virtual void accept(Visitor &visitor) = 0;
    
    virtual ~Element(){}
};

class ElementA: public Element {
public:
    void accept(Visitor &visitor) override {
        visitor.visitElementA(*this);
    }
   	// 实现方法
};

class ElementB: public Element {
public:
    void accept(Visitor &visitor) override {
        visitor.visitElementB(*this);
    }
    // 实现方法
};

class Visitor {	// 稳定
public:
    virtual void visitElementA(ElementA &element) = 0;
    virtual void visitElementB(ElementB &element) = 0;
    virtual ~Visitor(){};
};

// =================
// 扩展
class Visitor1: public Visitor {
public:
    void visitElementA(ElementA &element) override {
        cout << "Visitor1 is processing ElementA" << endl;
    }
    
    void visitElementB(ElementB &element) override {
        cout << "Visitor1 is processing ElementB" << endl;
    }
};

class Visitor2: public Visitor {
public:
    void visitElementA(ElementA &element) override {
        cout << "Visitor2 is processing ElementA" << endl;
    }
    
    void visitElementB(ElementB &element) override {
        cout << "Visitor2 is processing ElementB" << endl;
    }
};

int main() {
    Visitor2 visitor;
    ElementB elementB;
    elementB.accept(visitor);	// 动态添加操作
    
    ElementA elemantA;
    elementA.accept(visitor);
}

《设计模式》GoF：表示一个作用于某对象结构中的各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用于这些元素的新操作（变化）

要点：

• Visitor模式通过所谓双重分发（double dispatch）来实现在不更改（不添加新的操作-编译时）Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作（支持变化）
• 所谓双重分发即Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept方法的多态辨析；第二个为visitElementX方法的多态辨析
• Visitor模式最大的缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于”Element类层次结构稳定，而其中的操作却经常面临频繁改动”

“领域规则”模式

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

典型模式：

• Interpreter

Interpreter 解析器

动机：

• 在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化
• 在这种情况下，将特定领域的问题表达为某种语言语法规则下的句子，然后构建一个解析器来解释这样的句子，从而达到解决问题的目的

《设计模式》GoF：给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子

要点：

• Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足”业务规则频繁变化，且类似的结构不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式
• 使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧来方便地”扩展”文法
• Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interpreter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具

结构：