设计模式讲解

目录

设计模式分类

设计模式七大原则

1 工厂模式

1.1 简单工厂模式

1.2 工厂方法模式

1.3 抽象工厂模式

2 策略模式

3 适配器模式

4 单例模式

4.1 懒汉单例模式

4.2 饿汉单例模式

5 原型模式

6 模板模式

7 建造者模式

8 外观模式

9 组合模式

10 代理模式

11 享元模式

12 桥接模式

13 装饰器模式

14 备忘录模式

15 中介者模式

16 职责链模式

17 观察者模式

18 状态模式

---

设计模式分类

 总体来说设计模式分为三大类：

1. 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
2. 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
3. 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

设计模式七大原则

     参考：(81条消息) OOP的六大原则_贺三十的博客-CSDN博客

              (81条消息) 面向对象编程（OOP）的六大原则_西湖漫步的博客-CSDN博客_oop六大原则

1. 单一职责原则：避免相同的职责分散到不同的类中、避免一个类承担太多职责；减少类的耦合，提高类的复用性；
2. 接口隔离原则：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个专门的接口，比使用单个接口（多个接口方法集合到一个的接口）要好；
3. 开放=封闭原则：一个模块在拓展性方面应该是开放的，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。而在更改性方面应该是封闭的；
4. 里氏替换原则：子类型必须能够替换他们的父类型、并出现在父类能够出现的任何地方；
   1. 父类的方法都要在子类中实现或重写，并且派生类只实现其抽象类中生命的方法，而不应该给出多余的方法定义或实现。
   2. 子类与父类之间应该满足的关系，子类可以去扩展父类的功能，增加方法，但是不能改变父类原有的功能。
5. 依赖倒置原则：上层模块不应该依赖于下层模块，他们共同依赖于一个抽象，即：父类不能依赖子类，他们都依赖抽象类。面向接口编程，依赖于抽象而不依赖于具体，写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
6. 迪米特原则：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。当我们在编写一个类时，这个类的属性能私有化就私有化，尽量不与其他类产生联系。一个对象应该对其他对象保持最少的了解，简单的理解就是高内聚，低耦合。
7. 合成复用原则：尽量使用合成/聚合的方式，而不是使用继承。合成复用原则，要求在软件复用时，要先尽量使用组合或者聚合等关联关系实现，其次才考虑使用继承。也就是在一个新对象里通过关联的方式使用已有对象的一些方法和功能。
   1. 通常类的复用可以分为继承和合成，继承复用虽然简单，但是存在很大的缺点：
      1. 耦合度高，父类代码的修改会影响到子类，不利于代码的维护。
      2. 破坏了类的封装性，因为继承会将父类的实现细节暴露给子类，所以又叫做 “白箱” 复用。
      3. 限制了复用的灵活性，从父类继承来的实现是静态的，在运行期是无法改变的。
   2. 通常类的复用可以分为继承和合成，继承复用虽然简单，但是存在很大的缺点：
      1. 不会破坏封装性，因为新对象只能调用已有对象暴露出来的方法，所以又叫做 “黑箱” 复用。
      2. 耦合度低，已有对象的变化对新对象的影响较小，可以在新对象的中，根据需要调用已有对象的一些操作。
      3. 复用的灵活性高，可以在代码的运行中，动态选择相同类型的其他具体类。

后面参考：C++ 常用设计模式 - 小肚哥 - 博客园

                  C++各类设计模式及实现详解_Seven-CSDN博客_c++设计模式

1 工厂模式

在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。工厂模式作为一种创建模式，一般在创建复杂对象时，考虑使用；在创建简单对象时，建议直接new完成一个实例对象的创建。

总结：通过工厂类的成员函数去创建产品对象并返回，定义一个产品抽象类指针来接受。

1.1 简单工厂模式

主要特点是需要在工厂类中做判断，从而创造相应的产品，当增加新产品时，需要修改工厂类。使用简单工厂模式，我们只需要知道具体的产品型号就可以创建一个产品。

缺点：工厂类集中了所有产品类的创建逻辑，如果产品量较大，会使得工厂类变的非常臃肿。

#include <iostream>
#include <string>

using namespace std;

//定义产品类型信息
typedef enum
{
    Tank_Type_56 = 0,
    Tank_Type_96,
    Tank_Type_Num
}Tank_Type;

//抽象产品类
class Tank
{
public:
    virtual const string& type() = 0;
    virtual ~Tank()
    {

    }
};

//具体的产品类
class Tank56 : public Tank
{
public:
    Tank56():Tank(),m_strType("Tank56")
    {
    }

    const string& type() override
    {
        cout << m_strType.data() << endl;
        return m_strType;
    }
private:
    string m_strType;
};

//具体的产品类
class Tank96 : public Tank
{
public:
    Tank96():Tank(),m_strType("Tank96")
    {
    }
    const string& type() override
    {
        cout << m_strType.data() << endl;
        return m_strType;
    }

private:
    string m_strType;
};

//工厂类
class TankFactory
{
public:
    //根据产品信息创建具体的产品类实例，返回一个抽象产品类
    Tank* createTank(Tank_Type type)
    {
        switch(type)
        {
        case Tank_Type_56:
            return new Tank56();
        case Tank_Type_96:
            return new Tank96();
        default:
            return nullptr;
        }
    }

};

int main()
{
    TankFactory* factory = new TankFactory();
    Tank* tank56 = factory->createTank(Tank_Type_56);
    tank56->type();
    Tank* tank96 = factory->createTank(Tank_Type_96);
    tank96->type();
    delete tank96;
    tank96 = nullptr;
    delete tank56;
    tank56 = nullptr;
    delete factory;
    factory = nullptr;
    return 0;
}

1.2 工厂方法模式

定义一个创建对象的接口，其子类去具体现实这个接口以完成具体的创建工作。如果需要增加新的产品类，只需要扩展一个相应的工厂类即可。

缺点：产品类数据较多时，需要实现大量的工厂类，这无疑增加了代码量。

#include <iostream>
#include <string>

using namespace std;

//定义产品类型信息
typedef enum
{
    Tank_Type_56 = 0,
    Tank_Type_96,
    Tank_Type_Num
}Tank_Type;

//抽象产品类
class Tank
{
public:
    virtual const string& type() = 0;
    virtual ~Tank()
    {

    }
};

//具体的产品类
class Tank56 : public Tank
{
public:
    Tank56():Tank(),m_strType("Tank56")
    {
    }

    const string& type() override
    {
        cout << m_strType.data() << endl;
        return m_strType;
    }
private:
    string m_strType;
};

//具体的产品类
class Tank96 : public Tank
{
public:
    Tank96():Tank(),m_strType("Tank96")
    {
    }
    const string& type() override
    {
        cout << m_strType.data() << endl;
        return m_strType;
    }

private:
    string m_strType;
};

//抽象工厂类，提供一个创建接口
class TankFactory
{
public:
    //提供创建产品实例的接口，返回抽象产品类
    virtual Tank* createTank() = 0;
    virtual ~TankFactory(){}
};

//具体的创建工厂类，使用抽象工厂类提供的接口，去创建具体的产品实例
class Tank56Factory : public TankFactory
{
public:
    Tank* createTank() override
    {
        return new Tank56();
    }
};

//具体的创建工厂类，使用抽象工厂类提供的接口，去创建具体的产品实例
class Tank96Factory : public TankFactory
{
public:
    Tank* createTank() override
    {
        return new Tank96();
    }
};

int main()
{
    TankFactory* factory56 = new Tank56Factory();
    Tank* tank56 = factory56->createTank();
    tank56->type();

    TankFactory* factory96 = new Tank96Factory();
    Tank* tank96 = factory96->createTank();
    tank96->type();

    delete tank96;
    tank96 = nullptr;
    delete factory96;
    factory96 = nullptr;

    delete tank56;
    tank56 = nullptr;
    delete factory56;
    factory56 = nullptr;
    return 0;
}

1.3 抽象工厂模式

抽象工厂模式提供创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

当存在多个产品系列，而客户端只使用一个系列的产品时，可以考虑使用抽象工厂模式。

缺点：当增加一个新系列的产品时，不仅需要现实具体的产品类，还需要增加一个新的创建接口，扩展相对困难。

#include <iostream>
#include <string>

using namespace std;

/*
* 关键代码：在一个工厂里聚合多个同类产品。
* 以下代码以白色衣服和黑色衣服为例，白色衣服为一个产品系列，黑色衣服为一个产品系列。
* 白色上衣搭配白色裤子，   黑色上衣搭配黑色裤字。每个系列的衣服由一个对应的工厂创建，
* 这样一个工厂创建的衣服能保证衣服为同一个系列。
*/

//抽象上衣类
class Coat
{
public:
    virtual const string& color() = 0;
    virtual ~Coat(){}
};

//黑色上衣类
class BlackCoat : public Coat
{
public:
    BlackCoat():Coat(),m_strColor("Black Coat")
    {
    }

    const string& color() override
    {
        cout << m_strColor.data() << endl;
        return m_strColor;
    }
private:
    string m_strColor;
};

//白色上衣类
class WhiteCoat : public Coat
{
public:
    WhiteCoat():Coat(),m_strColor("White Coat")
    {
    }
    const string& color() override
    {
        cout << m_strColor.data() << endl;
        return m_strColor;
    }

private:
    string m_strColor;
};

//抽象裤子类
class Pants
{
public:
    virtual const string& color() = 0;
    virtual ~Pants(){}
};

//黑色裤子类
class BlackPants : public Pants
{
public:
    BlackPants():Pants(),m_strColor("Black Pants")
    {
    }
    const string& color() override
    {
        cout << m_strColor.data() << endl;
        return m_strColor;
    }

private:
    string m_strColor;
};

//白色裤子类
class WhitePants : public Pants
{
public:
    WhitePants():Pants(),m_strColor("White Pants")
    {
    }
    const string& color() override
    {
        cout << m_strColor.data() << endl;
        return m_strColor;
    }

private:
    string m_strColor;
};

//抽象工厂类，提供衣服创建接口
class Factory
{
public:
    //上衣创建接口，返回抽象上衣类
    virtual Coat* createCoat() = 0;
    //裤子创建接口，返回抽象裤子类
    virtual Pants* createPants() = 0;
    virtual ~Factory(){}
};

//创建白色衣服的工厂类，具体实现创建白色上衣和白色裤子的接口
class WhiteFactory : public Factory
{
public:
    Coat* createCoat() override
    {
        return new WhiteCoat();
    }

    Pants* createPants() override
    {
        return new WhitePants();
    }
};

//创建黑色衣服的工厂类，具体实现创建黑色上衣和黑色裤子的接口
class BlackFactory : public Factory
{
public:
    Coat* createCoat() override
    {
        return new BlackCoat();
    }

    Pants* createPants() override
    {
        return new BlackPants();
    }
};

int main()
{
    WhiteFactory *factoryWhite = new WhiteFactory();
    Coat *coatWhite = factoryWhite->createCoat();
    Pants *pantsWhite = factoryWhite->createPants();
    coatWhite->color();
    pantsWhite->color();
    delete factoryWhite;
    delete coatWhite;
    delete pantsWhite;

    BlackFactory *factoryBlack = new BlackFactory();
    Coat *coatBlack = factoryBlack->createCoat();
    Pants *pantsBlack = factoryBlack->createPants();
    coatBlack->color();
    pantsBlack->color();
    delete factoryBlack;
    delete coatBlack;
    delete pantsBlack;
    return 0;
}

2 策略模式

策略模式是指定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。也就是说这些算法所完成的功能一样，对外的接口一样，只是各自实现上存在差异。用策略模式来封装算法，效果比较好。

相比于使用大量的if...else，使用策略模式可以降低复杂度，使得代码更容易维护。

缺点：可能需要定义大量的策略类，并且这些策略类都要提供给客户端。

总结：在策略类将功能抽象类作为成员变量，通过策略类构造函数来判断具体实现那个功能类。

 什么是Cache的替换算法呢？简单解释一下， 当发生Cache缺失时，Cache控制器必须选择Cache中的一行，并用欲获得的数据来替换它。所采用的选择策略就是Cache的替换算法。

       ReplaceAlgorithm是一个抽象类，定义了算法的接口，有三个类继承自这个抽象类，也就是具体的算法实现。Cache类中需要使用替换算法，因此维护了一个  ReplaceAlgorithm的对象。

 首先给出替换算法的定义：

//抽象接口  
class ReplaceAlgorithm  
{  
public:  
    virtual void Replace() = 0;  
};  
//三种具体的替换算法  
class LRU_ReplaceAlgorithm : public ReplaceAlgorithm  
{  
public:  
    void Replace() { cout<<"Least Recently Used replace algorithm"<<endl; }  
};  
  
class FIFO_ReplaceAlgorithm : public ReplaceAlgorithm  
{  
public:  
    void Replace() { cout<<"First in First out replace algorithm"<<endl; }  
};  

class Random_ReplaceAlgorithm: public ReplaceAlgorithm  
{  
public:  
    void Replace() { cout<<"Random replace algorithm"<<endl; }  
};  

接着给出Cache的定义，这里很关键，Cache的实现方式直接影响了客户的使用方式，其关键在于如何指定替换算法。

 方式一：直接通过参数指定，传入一个特定算法的指针。

//Cache需要用到替换算法
class Cache
{
private:
	ReplaceAlgorithm *m_ra;
public:
	Cache(ReplaceAlgorithm *ra) { m_ra = ra; }
	~Cache() { delete m_ra; }
	void Replace() { m_ra->Replace(); }
};

如果用这种方式，客户就需要知道这些算法的具体定义。只能以下面这种方式使用，可以看到暴露了太多的细节。

int main()
{
	Cache cache(new LRU_ReplaceAlgorithm()); //暴露了算法的定义
	cache.Replace();
	return 0;
}

   方式二：也是直接通过参数指定，只不过不是传入指针，而是一个标签。这样客户只要知道算法的相应标签即可，而不需要知道算法的具体定义。

//Cache需要用到替换算法
enum RA{LRU, FIFO, RANDOM}; //标签
class Cache
{
private:
	ReplaceAlgorithm *m_ra;
public:
	Cache(enum RA ra) 
	{ 
		if(ra == LRU)
			m_ra = new LRU_ReplaceAlgorithm();
		else if(ra == FIFO)
			m_ra = new FIFO_ReplaceAlgorithm();
		else if(ra == RANDOM)
			m_ra = new Random_ReplaceAlgorithm();
		else 
			m_ra = NULL;
	}
	~Cache() { delete m_ra; }
	void Replace() { m_ra->Replace(); }
};

 相比方式一，这种方式用起来方便多了。其实这种方式将简单工厂模式与策略模式结合在一起，算法的定义使用了策略模式，而Cache的定义其实使用了简单工厂模式。

int main()
{
	Cache cache(LRU); //指定标签即可
	cache.Replace();
	return 0;
}

上面两种方式，构造函数都需要形参。构造函数是否可以不用参数呢？下面给出第三种实现方式。

方式三：利用模板实现。算法通过模板的实参指定。当然了，还是使用了参数，只不过不是构造函数的参数。在策略模式中，参数的传递难以避免，客户必须指定某种算法。

//Cache需要用到替换算法
template <class RA>
class Cache
{
private:
	RA m_ra;
public:
	Cache() { }
	~Cache() { }
	void Replace() { m_ra.Replace(); }
};

int main()
{
	Cache<Random_ReplaceAlgorithm> cache; //模板实参
	cache.Replace();
	return 0;
}

3 适配器模式

适配器模式将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。它包括类适配器和对象适配器，本文针对的是对象适配器。

适配器模式（Adapter）包含以下主要角色：

1. 目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。
2.  适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。
3. 适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。

参考：最常用的设计模式---适配器模式（C++实现）_黄花寒-CSDN博客_适配器模式c++

适配器模式有两种：

1. 类的适配器；
2. 对象适配器。

示例：在STL中就用到了适配器模式。STL实现了一种数据结构，称为双端队列（deque），支持前后两段的插入与删除。STL实现栈和队列时，没有从头开始定义它们，而是直接使用双端队列实现的。这里双端队列就扮演了适配器的角色。队列用到了它的后端插入，前端删除。而栈用到了它的后端插入，后端删除。假设栈和队列都是一种顺序容器，有两种操作：压入和弹出。
 

对象适配器实现：

#include <iostream>
#include <string>

using namespace std;

//适配者类（双端队列）
class Deque
{
public:
    void push_back(int x) { cout<<"Deque push_back"<<endl; }
    void push_front(int x) { cout<<"Deque push_front"<<endl; }
    void pop_back() { cout<<"Deque pop_back"<<endl; }
    void pop_front() { cout<<"Deque pop_front"<<endl; }
};

//适配器类（顺序容器）
class Sequence
{
public:
    virtual void push(int x) = 0;
    virtual void pop() = 0;
    virtual ~Sequence(){}
};

//目标接口类（栈）
class Stack: public Sequence
{
public:
    void push(int x) { deque.push_back(x); }
    void pop() { deque.pop_back(); }
private:
    Deque deque; //双端队列
};

//目标接口类（队列）
class Queue: public Sequence
{
public:
    void push(int x) { deque.push_back(x); }
    void pop() { deque.pop_front(); }
private:
    Deque deque; //双端队列
};

int main()
{
    Sequence *s1 = new Stack();
    Sequence *s2 = new Queue();
    s1->push(1);
    s1->pop();
    s2->push(1);
    s2->pop();
    delete s1;
    delete s2;
    return 0;
}

类的适配器实现：

#include <iostream>
#include <string>

using namespace std;

//适配者类（双端队列）
class Deque
{
public:
    void push_back(int x) { cout<<"Deque push_back"<<endl; }
    void push_front(int x) { cout<<"Deque push_front"<<endl; }
    void pop_back() { cout<<"Deque pop_back"<<endl; }
    void pop_front() { cout<<"Deque pop_front"<<endl; }
};

//适配器类（顺序容器）
class Sequence
{
public:
    virtual void push(int x) = 0;
    virtual void pop() = 0;
    virtual ~Sequence(){}
};

//目标接口类(栈)
class Stack:public Sequence, private Deque
{
public:
    void push(int x)
    {
        push_front(x);
    }
    void pop()
    {
        pop_front();
    }
};

//目标接口类(队列)
class Queue:public Sequence, private Deque
{
public:
    void push(int x)
    {
        push_back(x);
    }
    void pop()
    {
        pop_front();
    }
};

int main()
{
    Stack *s1 = new Stack();
    Queue *s2 = new Queue();
    s1->push(1);
    s1->pop();
    s2->push(1);
    s2->pop();
    delete s1;
    delete s2;
    return 0;
}

4 单例模式

单例模式主要解决一个全局使用的类频繁的创建和销毁的问题。单例模式下可以确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

单例模式有三个要素：

1. 某个类只能有一个实例；
2. 它必须自行创建这个实例；
3. 它必须自行向整个系统提供这个实例；

单例模式分类：饿汉式和懒汉式。

4.1 懒汉单例模式

懒汉：故名思义，不到万不得已就不会去实例化类，也就是说在第一次用到类实例的时候才会去实例化一个对象。在访问量较小，甚至可能不会去访问的情况下，采用懒汉实现，这是以时间换空间。

/****************dome.h**************/
#ifndef DOME_H
#define DOME_H

#include <iostream>
#include <string>
#include <mutex>
using namespace std;

class Singleton
{

public:
    static Singleton* getInstance();
    void print(string str);

private:
    Singleton(){};  //构造函数私有foud
    Singleton(const Singleton&) = delete;            //明确拒绝
    Singleton& operator=(const Singleton&) = delete; //明确拒绝

    static Singleton* mSingleton;
};

#endif // DOME_H

/****************dome.cpp**************/
#include "dome.h"

std::mutex mt;
Singleton* Singleton::mSingleton = nullptr;

Singleton* Singleton::getInstance()
{
    if(mSingleton == nullptr)
    {
        mt.lock();
        if(mSingleton == nullptr)
        {
            mSingleton = new Singleton();
        }
        mt.unlock();
    }
    return mSingleton;
}

void Singleton::print(string str)
{
    std::cout<<"日志："<<str<<std::endl;
}

/****************main.cpp**************/
#include "dome.h"

int main()
{
    Singleton::getInstance()->print("hello world!");
    return 0;
}

4.2 饿汉单例模式

饿汉：饿了肯定要饥不择食。所以在单例类定义的时候就进行实例化。在访问量比较大，或者可能访问的线程比较多时，采用饿汉实现，可以实现更好的性能。这是以空间换时间。

/********************dome.h*********************/
#ifndef DOME_H
#define DOME_H

#include <iostream>
#include <string>
#include <mutex>
using namespace std;
class Singleton
{

public:
    static Singleton* getInstance();
    void print(string str);

private:
    Singleton(){};  //构造函数私有foud
    Singleton(const Singleton&) = delete;            //明确拒绝
    Singleton& operator=(const Singleton&) = delete; //明确拒绝

    static Singleton* mSingleton;
};

#endif // DOME_H

/********************dome.cpp*********************/
#include "dome.h"

Singleton* Singleton::mSingleton = new Singleton();

Singleton* Singleton::getInstance()
{
    return mSingleton;
}

void Singleton::print(string str)
{
    std::cout<<"日志："<<str<<std::endl;
}

/********************main.cpp*********************/
#include "dome.h"

int main()
{
    Singleton::getInstance()->print("hello world!");
    return 0;
}

5 原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。通俗的讲就是当需要创建一个新的实例化对象时，我们刚好有一个实例化对象，但是已经存在的实例化对象又不能直接使用。这种情况下拷贝一个现有的实例化对象来用，可能会更方便。

以下情形可以考虑使用原型模式：

1. 当new一个对象，非常繁琐复杂时，可以使用原型模式来进行复制一个对象。比如创建对象时，构造函数的参数很多，而自己又不完全的知道每个参数的意义，就可以使用原型模式来创建一个新的对象，不必去理会创建的过程。
2. 当需要new一个新的对象，这个对象和现有的对象区别不大，可能就几个属性不同而已，我们就可以直接复制一个已有的对象，然后稍加修改。
3. 当需要一个对象副本时，比如需要提供对象的数据，同时又需要避免外部对数据对象进行修改，那就拷贝一个对象副本供外部使用。例如：一个对象，经过一段处理之后，其内部的状态发生了变化；这个时候，我们需要一个这个状态的副本，如果直接new一个新的对象的话，但是它的状态是不对的，此时，可以使用原型模式，将原来的对象拷贝一个出来，这个对象就和之前的对象是完全一致的了。

#include <iostream>
#include <cstring>

using namespace std;

//父类
class Resume
{
protected:
    char *name;
    int age;
public:
    Resume() {}
    virtual ~Resume() {}
    virtual Resume* Clone() { return nullptr; }
    virtual void Show() {}
};

class ResumeA : public Resume
{
public:
    ResumeA(const char *str,int num);  //构造函数
    ResumeA(const ResumeA &r);         //拷贝构造函数
    ~ResumeA();                //析构函数
    ResumeA* Clone();          //克隆，关键所在
    void Show();               //显示内容
};

ResumeA::ResumeA(const char *str,int num)
{
    if(str == nullptr)
    {
        name = new char[1];
        name[0] = '\0';
    }
    else
    {
        name = new char[strlen(str)+1];
        strncpy(name,str,strlen(str)+1);
    }

    age = num;
}

ResumeA::~ResumeA()
{
    delete [] name;
}

ResumeA::ResumeA(const ResumeA &r)
{
    age = r.age;
    name = new char[strlen(r.name)+1];
    strncpy(name, r.name,strlen(r.name)+1);
}

//克隆，关键所在
ResumeA* ResumeA::Clone()
{
    return new ResumeA(*this);
}

void ResumeA::Show()
{
    cout<<"ResumeA name : age = "<<name<<" : "<<age<<endl;
}

int main()
{
    Resume *resume1 = new ResumeA("xiaoming",18);
    resume1->Show();

    Resume *resume2 = resume1->Clone(); //克隆
    resume2->Show();

    delete  resume1;
    delete  resume2;
}

6 模板模式

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

当多个类有相同的方法，并且逻辑相同，只是细节上有差异时，可以考虑使用模板模式。具体的实现上可以将相同的核心算法设计为模板方法，具体的实现细节有子类实现。

缺点:每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。

以生产电脑为例，电脑生产的过程都是一样的，只是一些装配的器件可能不同而已。

#include <iostream>

using namespace std;

class Computer
{
public:
    void product()
    {
        installCpu();
        installRam();
        installGraphicsCard();
    }

    virtual ~Computer(){}

protected:
    virtual void installCpu() = 0;
    virtual void installRam() = 0;
    virtual void installGraphicsCard() = 0;
};

class ComputerA : public Computer
{
public:
        ~ComputerA(){}
protected:
    void installCpu() override
    {
        cout << "ComputerA install Inter Core i5" << endl;
    }

    void installRam() override
    {
        cout << "ComputerA install 2G Ram" << endl;
    }

    void installGraphicsCard() override
    {
        cout << "ComputerA install Gtx940 GraphicsCard" << endl;
    }
};

class ComputerB : public Computer
{
public:
        ~ComputerB(){}
protected:
    void installCpu() override
    {
        cout << "ComputerB install Inter Core i7" << endl;
    }

    void installRam() override
    {
        cout << "ComputerB install 4G Ram" << endl;
    }

    void installGraphicsCard() override
    {
        cout << "ComputerB install Gtx960 GraphicsCard" << endl;
    }
};

int main()
{
    ComputerB* c1 = new ComputerB();
    c1->product();

    delete c1;
    c1 = nullptr;
    return 0;
}

7 建造者模式

建造者模式：将复杂对象的构建和其表示分离，使得相同的构建过程可以产生不同的表示。

以下情形可以考虑使用建造者模式：

1. 对象的创建复杂，但是其各个部分的子对象创建算法一定。
2. 需求变化大，构造复杂对象的子对象经常变化，但将其组合在一起的算法相对稳定。

建造者模式的优点：

1. 将对象的创建和表示分离，客户端不需要了解具体的构建细节。
2. 增加新的产品对象时，只需要增加其具体的建造类即可，不需要修改原来的代码，扩展方便。
3. 产品之间差异性大，内部变化较大、较复杂时不建议使用建造者模式。

《大话设计模式》举了一个很好的例子——建造小人，一共需建造6个部分，头部、身体、左右手、左右脚。与工厂模式不同，建造者模式是在导向者的控制下一步一步构造产品的。建造小人就是在控制下一步步构造出来的。创建者模式可以能更精细的控制构建过程，从而能更精细的控制所得产品的内部结构。对于客户来说，只需知道建造者就可以了，通过建造者，客户就能构造复杂的对象，而不需要知道具体的构造过程。下面给出小人例子的代码实现。

#include <iostream>

using namespace std;

//抽线产品
class Builder
{
public:
    virtual void BuildHead() {}
    virtual void BuildBody() {}
    virtual void BuildLeftArm(){}
    virtual void BuildRightArm() {}
    virtual void BuildLeftLeg() {}
    virtual void BuildRightLeg() {}
};

//具体产品，构造瘦人
class ThinBuilder : public Builder
{
public:
    void BuildHead() { cout<<"build thin body"<<endl; }
    void BuildBody() { cout<<"build thin head"<<endl; }
    void BuildLeftArm() { cout<<"build thin leftarm"<<endl; }
    void BuildRightArm() { cout<<"build thin rightarm"<<endl; }
    void BuildLeftLeg() { cout<<"build thin leftleg"<<endl; }
    void BuildRightLeg() { cout<<"build thin rightleg"<<endl; }
};
//具体产品，构造胖人
class FatBuilder : public Builder
{
public:
    void BuildHead() { cout<<"build fat body"<<endl; }
    void BuildBody() { cout<<"build fat head"<<endl; }
    void BuildLeftArm() { cout<<"build fat leftarm"<<endl; }
    void BuildRightArm() { cout<<"build fat rightarm"<<endl; }
    void BuildLeftLeg() { cout<<"build fat leftleg"<<endl; }
    void BuildRightLeg() { cout<<"build fat rightleg"<<endl; }
};

//建造者
class Director
{
private:
    Builder *m_pBuilder;    //产品对象
public:
    Director(Builder *builder) { m_pBuilder = builder; }
    void Create(){
        m_pBuilder->BuildHead();
        m_pBuilder->BuildBody();
        m_pBuilder->BuildLeftArm();
        m_pBuilder->BuildRightArm();
        m_pBuilder->BuildLeftLeg();
        m_pBuilder->BuildRightLeg();
    }
};

int main()
{
    FatBuilder thin;
    Director director(&thin);
    director.Create();
    return 0;
}

8 外观模式

外观模式应该是用的很多的一种模式，特别是当一个系统很复杂时，系统提供给客户的是一个简单的对外接口，而把里面复杂的结构都封装了起来。客户只需使用这些简单接口就能使用这个系统，而不需要关注内部复杂的结构。DP一书的定义：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

外观模式特点（摘自DP一书）：

1. 它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2. 它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。
3. 如果应用需要，它并不限制它们使用子系统类。

以下情形建议考虑外观模式：

1. 设计初期阶段，应有意识的将不同层分离，层与层之间建立外观模式。
2. 开发阶段，子系统越来越复杂，使用外观模式提供一个简单的调用接口。
3. 一个系统可能已经非常难易维护和扩展，但又包含了非常重要的功能，可以为其开发一个外观类，使得新系统可以方便的与其交互。

举个编译器的例子，假设编译一个程序需要经过四个步骤：词法分析、语法分析、中间代码生成、机器码生成。学过编译都知道，每一步都很复杂。对于编译器这个系统，就可以使用外观模式。可以定义一个高层接口，比如名为Compiler的类，里面有一个名为Run的函数。客户只需调用这个函数就可以编译程序，至于Run函数内部的具体操作，客户无需知道。

#include <iostream>

using namespace std;

class Scanner
{
public:
    void Scan() { cout<<"词法分析"<<endl; }
};
class Parser
{
public:
    void Parse() { cout<<"语法分析"<<endl; }
};
class GenMidCode
{
public:
    void GenCode() { cout<<"产生中间代码"<<endl; }
};
class GenMachineCode
{
public:
    void GenCode() { cout<<"产生机器码"<<endl;}
};

//高层接口
class Compiler
{
public:
    void Run()
    {
        Scanner scanner;
        Parser parser;
        GenMidCode genMidCode;
        GenMachineCode genMacCode;
        scanner.Scan();
        parser.Parse();
        genMidCode.GenCode();
        genMacCode.GenCode();
    }
};

int main()
{
    Compiler compiler;
    compiler.Run();
    return 0;
}

9 组合模式

     上面实现外观模式时，在Compiler这个类中包含了多个类的对象，就像把这些类组合在了一起。组合模式是不是这个意思，有点相似，其实不然。
      DP书上给出的定义：将对象组合成树形结构以表示“部分-整体”的层次结构。组合使得用户对单个对象和组合对象的使用具有一致性。注意两个字“树形”。既然讲到以树形结构表示“部分-整体”，那可以将组合模式想象成一根大树，将大树分成树枝和树叶两部分，树枝上可以再长树枝，也可以长树叶，树叶上则不能再长出别的东西。这种树形结构在现实生活中随处可见。

以下情况可以考虑使用组合模式：  

1.  希望表示对象的部分-整体层次结构。
2. 希望客户端忽略组合对象与单个对象的不同，客户端将统一的使用组合结构中的所有对象。

比如：一个集团公司，它有一个母公司，下设很多家子公司。不管是母公司还是子公司，都有各自直属的财务部、人力资源部、销售部等。对于母公司来说，不论是子公司，还是直属的财务部、人力资源部，都是它的部门。整个公司的部门拓扑图就是一个树形结构。

#include <iostream>
#include <list>

using namespace std;

class Company
{
public:
    Company(string name) { m_name = name; }
    virtual ~Company(){}
    virtual void Add(Company *pCom){}
    virtual void Show(int depth) {}
protected:
    string m_name;
};

//具体公司
class ConcreteCompany : public Company
{
public:
    ConcreteCompany(string name): Company(name) {}
    virtual ~ConcreteCompany() {}
    void Add(Company *pCom)  //位于树的中间，可以增加子树
    {
        m_listCompany.push_back(pCom);
    }
    void Show(int depth)
    {
        for(int i = 0;i < depth; i++)
            cout<<"-";
        cout<<m_name<<endl;
        list<Company *>::iterator iter=m_listCompany.begin();
        for(; iter != m_listCompany.end(); iter++) //显示下层结点
        {
            (*iter)->Show(depth + 2);
        }
    }
private:
    list<Company *> m_listCompany;
};

//具体的部门，财务部
class FinanceDepartment : public Company
{
public:
    FinanceDepartment(string name):Company(name){}
    virtual ~FinanceDepartment() {}
    virtual void Show(int depth) //只需显示，无限添加函数，因为已是叶结点
    {
        for(int i = 0; i < depth; i++)
            cout<<"-";
        cout<<m_name<<endl;
    }
};

//具体的部门，人力资源部
class HRDepartment :public Company
{
public:
    HRDepartment(string name):Company(name){}
    virtual ~HRDepartment() {}
    virtual void Show(int depth) //只需显示，无限添加函数，因为已是叶结点
    {
        for(int i = 0; i < depth; i++)
            cout<<"-";
        cout<<m_name<<endl;
    }
};


int main()
{
    Company *root = new ConcreteCompany("总公司");
    Company *leaf1=new FinanceDepartment("财务部");
    Company *leaf2=new HRDepartment("人力资源部");
    root->Add(leaf1);
    root->Add(leaf2);

    //分公司A
    Company *midA = new ConcreteCompany("分公司A");
    Company *leaf3=new FinanceDepartment("财务部");
    Company *leaf4=new HRDepartment("人力资源部");
    midA->Add(leaf3);
    midA->Add(leaf4);
    root->Add(midA);

    //分公司B
    Company *midB = new ConcreteCompany("分公司B");
    FinanceDepartment *leaf5=new FinanceDepartment("财务部");
    HRDepartment *leaf6=new HRDepartment("人力资源部");
    midB->Add(leaf5);
    midB->Add(leaf6);
    root->Add(midB);
    root->Show(0);

    delete leaf1; delete leaf2;
    delete leaf3; delete leaf4;
    delete leaf5; delete leaf6;
    delete midA; delete midB;
    delete root;
    return 0;
}

10 代理模式

代理模式：为其它对象提供一种代理以控制这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介作用。
有四种常用的情况：（1）远程代理，（2）虚代理，（3）保护代理，（4）智能引用。本文主要介绍虚代理和智能引用两种情况。

优点：

1. 职责清晰。真实的角色只负责实现实际的业务逻辑，不用关心其它非本职责的事务，通过后期的代理完成具体的任务。这样代码会简洁清晰。
2. 代理对象可以在客户端和目标对象之间起到中介的作用，这样就保护了目标对象。
3. 扩展性好。

这是[DP]一书上的给的例子：考虑一个可以在文档中嵌入图形对象的文档编辑器。有些图形对象的创建开销很大。但是打开文档必须很迅速，因此我们在打开文档时应避免一次性创建所有开销很大的对象。这里就可以运用代理模式，在打开文档时，并不打开图形对象，而是打开图形对象的代理以替代真实的图形。待到真正需要打开图形时，仍由代理负责打开。

#include <iostream>
#include <list>

using namespace std;

class Image
{
public:
    Image(string name): m_imageName(name) {}
    virtual ~Image() {}
    virtual void Show() {}
protected:
    string m_imageName;
};

class BigImage: public Image
{
public:
    BigImage(string name):Image(name) {}
    ~BigImage() {}
    void Show()
    {
        cout<<"Show big image : "<<m_imageName<<endl;
    }
};

class BigImageProxy: public Image
{
private:
    BigImage *m_bigImage;
public:
    BigImageProxy(string name):Image(name),m_bigImage(0) {}
    ~BigImageProxy() { delete m_bigImage; }
    void Show()
    {
        if(m_bigImage == NULL)
            m_bigImage = new BigImage(m_imageName);
        m_bigImage->Show();
    }
};


int main()
{
    Image *image = new BigImageProxy("proxy.jpg"); //代理
    image->Show(); //需要时由代理负责打开
    delete image;
    return 0;
}

11 享元模式

享元模式：运用共享技术有效地支持大量细粒度的对象。在有大量对象时，把其中共同的部分抽象出来，如果有相同的业务请求，直接返回内存中已有的对象，避免重新创建。

以下情况可以考虑使用享元模式：

1. 系统中有大量的对象，这些对象消耗大量的内存，且这些对象的状态可以被外部化。
2. 对于享元模式，需要将对象的信息分为两个部分：内部状态和外部状态。内部状态是指被共享出来的信息，储存在享元对象内部且不随环境变化而改变；外部状态是不可以共享的，它随环境改变而改变，是由客户端控制的。

举个围棋的例子，围棋的棋盘共有361格，即可放361个棋子。现在要实现一个围棋程序，该怎么办呢？首先要考虑的是棋子棋盘的实现，可以定义一个棋子的类，成员变量包括棋子的颜色、形状、位置等信息，另外再定义一个棋盘的类，成员变量中有个容器，用于存放棋子的对象。下面给出代码表示：

        棋子的定义，当然棋子的属性除了颜色和位置，还有其他的，这里略去。这两个属性足以说明问题。

//棋子颜色
enum PieceColor {BLACK, WHITE};
//棋子位置
struct PiecePos
{
	int x;
	int y;
	PiecePos(int a, int b): x(a), y(b) {}
};
//棋子定义
class Piece
{
protected:
	PieceColor m_color; //颜色
	PiecePos m_pos;     //位置
public:
	Piece(PieceColor color, PiecePos pos): m_color(color), m_pos(pos) {}
	~Piece() {}
	virtual void Draw() {}
};
class BlackPiece: public Piece
{
public:
	BlackPiece(PieceColor color, PiecePos pos): Piece(color, pos) {}
	~BlackPiece() {}
	void Draw() { cout<<"绘制一颗黑棋"<<endl;}
};
class WhitePiece: public Piece
{
public:
	WhitePiece(PieceColor color, PiecePos pos): Piece(color, pos) {}
	~WhitePiece() {}
	void Draw() { cout<<"绘制一颗白棋"<<endl;}
};

棋盘的定义：

class PieceBoard
{
private:
	vector<Piece*> m_vecPiece; //棋盘上已有的棋子
	string m_blackName; //黑方名称
	string m_whiteName; //白方名称
public:
	PieceBoard(string black, string white): m_blackName(black), m_whiteName(white){}
	~PieceBoard() { Clear(); }
	void SetPiece(PieceColor color, PiecePos pos) //一步棋，在棋盘上放一颗棋子
	{
		Piece * piece = NULL;
		if(color == BLACK) //黑方下的
		{	
			piece = new BlackPiece(color, pos); //获取一颗黑棋
			cout<<m_blackName<<"在位置("<<pos.x<<','<<pos.y<<")";
			piece->Draw(); //在棋盘上绘制出棋子
		}
		else
		{	
			piece = new WhitePiece(color, pos);
			cout<<m_whiteName<<"在位置("<<pos.x<<','<<pos.y<<")";
			piece->Draw();
		}
		m_vecPiece.push_back(piece);  //加入容器中
	}
	void Clear() //释放内存
	{
		int size = m_vecPiece.size();
		for(int i = 0; i < size; i++)
			delete m_vecPiece[i];
	}
};

 客户的使用方式如下：

int main()
{
	PieceBoard pieceBoard("A","B");
	pieceBoard.SetPiece(BLACK, PiecePos(4, 4));
	pieceBoard.SetPiece(WHITE, PiecePos(4, 16));
	pieceBoard.SetPiece(BLACK, PiecePos(16, 4));
	pieceBoard.SetPiece(WHITE, PiecePos(16, 16));
}

可以发现，棋盘的容器中存放了已下的棋子，而每个棋子包含棋子的所有属性。一盘棋往往需要含上百颗棋子，采用上面这种实现，占用的空间太大了。如何改进呢？用享元模式。其定义为：运用共享技术有效地支持大量细粒度的对象。

        在围棋中，棋子就是大量细粒度的对象。其属性有内在的，比如颜色、形状等，也有外在的，比如在棋盘上的位置。内在的属性是可以共享的，区分在于外在属性。因此，可以这样设计，只需定义两个棋子的对象，一颗黑棋和一颗白棋，这两个对象含棋子的内在属性；棋子的外在属性，即在棋盘上的位置可以提取出来，存放在单独的容器中。相比之前的方案，现在容器中仅仅存放了位置属性，而原来则是棋子对象。显然，现在的方案大大减少了对于空间的需求。

       关注PieceBoard 的容器，之前是vector<Piece*> m_vecPiece，现在是vector<PiecePos> m_vecPos。这里是关键。

   棋子的新定义，只包含内在属性：
 

//棋子颜色
enum PieceColor {BLACK, WHITE};
//棋子位置
struct PiecePos
{
	int x;
	int y;
	PiecePos(int a, int b): x(a), y(b) {}
};
//棋子定义
class Piece
{
protected:
	PieceColor m_color; //颜色
public:
	Piece(PieceColor color): m_color(color) {}
	~Piece() {}
	virtual void Draw() {}
};
class BlackPiece: public Piece
{
public:
	BlackPiece(PieceColor color): Piece(color) {}
	~BlackPiece() {}
	void Draw() { cout<<"绘制一颗黑棋\n"; }
};
class WhitePiece: public Piece
{
public:
	WhitePiece(PieceColor color): Piece(color) {}
	~WhitePiece() {}
	void Draw() { cout<<"绘制一颗白棋\n";}
};

  相应棋盘的定义为：

class PieceBoard
{
private:
	vector<PiecePos> m_vecPos; //存放棋子的位置
	Piece *m_blackPiece;       //黑棋棋子 
	Piece *m_whitePiece;       //白棋棋子
	string m_blackName;
	string m_whiteName;
public:
	PieceBoard(string black, string white): m_blackName(black), m_whiteName(white)
	{
		m_blackPiece = NULL;
		m_whitePiece = NULL;
	}
	~PieceBoard() { delete m_blackPiece; delete m_whitePiece;}
	void SetPiece(PieceColor color, PiecePos pos)
	{
		if(color == BLACK)
		{
			if(m_blackPiece == NULL)  //只有一颗黑棋
				m_blackPiece = new BlackPiece(color);	
			cout<<m_blackName<<"在位置("<<pos.x<<','<<pos.y<<")";
			m_blackPiece->Draw();
		}
		else
		{
			if(m_whitePiece == NULL)
				m_whitePiece = new WhitePiece(color);
			cout<<m_whiteName<<"在位置("<<pos.x<<','<<pos.y<<")";
			m_whitePiece->Draw();
		}
		m_vecPos.push_back(pos);
	}
};

客户的使用方式一样，这里不重复给出。

12 桥接模式

桥接模式：将抽象部分与实现部分分离，使它们都可以独立变换。

以下情形考虑使用桥接模式：

1. 当一个对象有多个变化因素的时候，考虑依赖于抽象的实现，而不是具体的实现。
2. 当多个变化因素在多个对象间共享时，考虑将这部分变化的部分抽象出来再聚合/合成进来。
3. 当一个对象的多个变化因素可以动态变化的时候。

优点：

1. 将实现抽离出来，再实现抽象，使得对象的具体实现依赖于抽象，满足了依赖倒转原则。
2. 更好的可扩展性。
3. 可动态的切换实现。桥接模式实现了抽象和实现的分离，在实现桥接模式时，就可以实现动态的选择具体的实现。

示例：考虑装操作系统，有多种配置的计算机，同样也有多款操作系统。如何运用桥接模式呢？可以将操作系统和计算机分别抽象出来，让它们各自发展，减少它们的耦合度。当然了，两者之间有标准的接口。这样设计，不论是对于计算机，还是操作系统都是非常有利的。

#include <iostream>

using namespace std;

//操作系统
class OS
{
public:
    virtual void InstallOS_Imp() {}
};
class WindowOS: public OS
{
public:
    void InstallOS_Imp() { cout<<"安装Window操作系统"<<endl; }
};
class LinuxOS: public OS
{
public:
    void InstallOS_Imp() { cout<<"安装Linux操作系统"<<endl; }
};
class UnixOS: public OS
{
public:
    void InstallOS_Imp() { cout<<"安装Unix操作系统"<<endl; }
};
//计算机
class Computer
{
public:
    virtual void InstallOS(OS *os) {}
};
class DellComputer: public Computer
{
public:
    void InstallOS(OS *os) { os->InstallOS_Imp(); }
};
class AppleComputer: public Computer
{
public:
    void InstallOS(OS *os) { os->InstallOS_Imp(); }
};
class HPComputer: public Computer
{
public:
    void InstallOS(OS *os) { os->InstallOS_Imp(); }
};


int main()
{
    OS *os1 = new WindowOS();
    OS *os2 = new LinuxOS();
    Computer *computer1 = new AppleComputer();
    computer1->InstallOS(os1);
    computer1->InstallOS(os2);
}

13 装饰器模式

装饰模式：动态地给一个对象添加一些额外的功能，它是通过创建一个包装对象，也就是装饰来包裹真实的对象。新增加功能来说，装饰器模式比生产子类更加灵活。

以下情形考虑使用装饰模式：

1. 需要扩展一个类的功能，或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

有时我们希望给某个对象而不是整个类添加一些功能。比如有一个手机，允许你为手机添加特性，比如增加挂件、屏幕贴膜等。一种灵活的设计方式是，将手机嵌入到另一对象中，由这个对象完成特性的添加，我们称这个嵌入的对象为装饰。这个装饰与它所装饰的组件接口一致，因此它对使用该组件的客户透明。

 在这种设计中，手机的装饰功能被独立出来，可以单独发展，进而简化了具体手机类的设计。下面给出Phone类的实现：

#include <iostream>

using namespace std;


//公共抽象类（手机）
class Phone
{
public:
    Phone() {}
    virtual ~Phone() {}
    virtual void ShowDecorate() {}
};

/*具体的手机类的定义*/
//具体的手机类
class iPhone : public Phone
{
private:
    string m_name; //手机名称
public:
    iPhone(string name): m_name(name){}
    ~iPhone() {}
    void ShowDecorate() { cout<<m_name<<"的装饰"<<endl;}
};
//具体的手机类
class NokiaPhone : public Phone
{
private:
    string m_name;
public:
    NokiaPhone(string name): m_name(name){}
    ~NokiaPhone() {}
    void ShowDecorate() { cout<<m_name<<"的装饰"<<endl;}
};

/*装饰类的实现*/
//装饰类
class DecoratorPhone : public Phone
{
private:
    Phone *m_phone;  //要装饰的手机
public:
    DecoratorPhone(Phone *phone): m_phone(phone) {}
    virtual void ShowDecorate() { m_phone->ShowDecorate(); }
};
//具体的装饰类
class DecoratorPhoneA : public DecoratorPhone
{
public:
    DecoratorPhoneA(Phone *phone) : DecoratorPhone(phone) {}
    void ShowDecorate() { DecoratorPhone::ShowDecorate(); AddDecorate(); }
private:
    void AddDecorate() { cout<<"增加挂件"<<endl; } //增加的装饰
};
//具体的装饰类
class DecoratorPhoneB : public DecoratorPhone
{
public:
    DecoratorPhoneB(Phone *phone) : DecoratorPhone(phone) {}
    void ShowDecorate() { DecoratorPhone::ShowDecorate(); AddDecorate(); }
private:
    void AddDecorate() { cout<<"屏幕贴膜"<<endl; } //增加的装饰
};

/*客户使用方式*/
int main()
{
    Phone *iphone = new NokiaPhone("6300");
    Phone *dpa = new DecoratorPhoneA(iphone); //装饰，增加挂件
    Phone *dpb = new DecoratorPhoneB(dpa);    //装饰，屏幕贴膜
    dpb->ShowDecorate();
    delete dpa;
    delete dpb;
    delete iphone;
    return 0;
}

14 备忘录模式

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

备忘录模式中需要定义的角色类：

1. Originator(发起人)：负责创建一个备忘录Memento，用以记录当前时刻自身的内部状态，并可使用备忘录恢复内部状态。Originator可以根据需要决定Memento存储自己的哪些内部状态。
2. Memento(备忘录)：负责存储Originator对象的内部状态，并可以防止Originator以外的其他对象访问备忘录。备忘录有两个接口：Caretaker只能看到备忘录的窄接口，他只能将备忘录传递给其他对象。Originator却可看到备忘录的宽接口，允许它访问返回到先前状态所需要的所有数据。
3. Caretaker(管理者):负责备忘录Memento，不能对Memento的内容进行访问或者操作。

举个简单的例子，我们玩游戏时都会保存进度，所保存的进度以文件的形式存在。这样下次就可以继续玩，而不用从头开始。这里的进度其实就是游戏的内部状态，而这里的文件相当于是在游戏之外保存状态。这样，下次就可以从文件中读入保存的进度，从而恢复到原来的状态。这就是备忘录模式。

Memento类定义了内部的状态，而Caretake类是一个保存进度的管理者，GameRole类是游戏角色类。可以看到GameRole的对象依赖于Memento对象，而与Caretake对象无关。下面给出一个简单的是实现。

#include <iostream>
#include <vector>

using namespace std;


//需保存的信息
class Memento
{
public:
    int m_vitality; //生命值
    int m_attack;   //进攻值
    int m_defense;  //防守值
public:
    Memento(int vitality, int attack, int defense):
      m_vitality(vitality),m_attack(attack),m_defense(defense){}
    Memento& operator=(const Memento &memento)
    {
        m_vitality = memento.m_vitality;
        m_attack = memento.m_attack;
        m_defense = memento.m_defense;
        return *this;
    }
};
//游戏角色
class GameRole
{
private:
    int m_vitality;
    int m_attack;
    int m_defense;
public:
    GameRole(): m_vitality(100),m_attack(100),m_defense(100) {}
    Memento Save()  //保存进度，只与Memento对象交互，并不牵涉到Caretake
    {
        Memento memento(m_vitality, m_attack, m_defense);
        return memento;
    }
    void Load(Memento memento)  //载入进度，只与Memento对象交互，并不牵涉到Caretake
    {
        m_vitality = memento.m_vitality;
        m_attack = memento.m_attack;
        m_defense = memento.m_defense;
    }
    void Show() { cout<<"vitality : "<< m_vitality<<", attack : "<< m_attack<<", defense : "<< m_defense<<endl; }
    void Attack() { m_vitality -= 10; m_attack -= 10;  m_defense -= 10; }
};
//保存的进度库
class Caretake
{
public:
    Caretake() {}
    void Save(Memento menento) { m_vecMemento.push_back(menento); }
    Memento Load(int state) { return m_vecMemento[state]; }
private:
    vector<Memento> m_vecMemento;
};

/* 客户使用方式*/
//测试案例
int main()
{
    Caretake caretake;
    GameRole role;
    role.Show();   //初始值
    caretake.Save(role.Save()); //保存状态
    role.Attack();
    role.Show();  //进攻后
    role.Load(caretake.Load(0)); //载入状态
    role.Show();  //恢复到状态0
    return 0;
}

15 中介者模式

中介者模式：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之前的交互。

如果对象与对象之前存在大量的关联关系，若一个对象改变，常常需要跟踪与之关联的对象，并做出相应的处理，这样势必会造成系统变得复杂，遇到这种情形可以考虑使用中介者模式。当多个对象存在关联关系时，为它们设计一个中介对象，当一个对象改变时，只需要通知它的中介对象，再由它的中介对象通知每个与它相关的对象。

 本文就以租房为例子：如果没有房屋中介，那么房客要自己找房东，而房东也要自己找房客，非常不方便。有了房屋中介机构就方便了，房东可以把要出租的房屋信息放到中介机构，而房客可以去中介机构咨询。在软件中，就是多个对象之间需要通信，如果没有中介，对象就需要知道其他对象，最坏情况下，可能需要知道所有其他对象，而有了中介对象就方便多了，对象只需与中介对象通信，而不用知道其他的对象。这就是中介者模式，下面以租房为例。

#include <iostream>
#include <vector>

using namespace std;


class Mediator;
//抽象人
class Person
{
protected:
    Mediator *m_mediator; //中介
public:
    virtual void SetMediator(Mediator *mediator){} //设置中介
    virtual void SendMessage(string message) {}    //向中介发送信息
    virtual void GetMessage(string message) {}     //从中介获取信息
};
//抽象中介机构
class Mediator
{
public:
    virtual void Send(string message, Person *person) {}
    virtual void SetA(Person *A) {}  //设置其中一方
    virtual void SetB(Person *B) {}
};
//租房者
class Renter: public Person
{
public:
    void SetMediator(Mediator *mediator) { m_mediator = mediator; }
    void SendMessage(string message) { m_mediator->Send(message, this); }
    void GetMessage(string message) { cout<<"租房者收到信息"<<message; }
};
//房东
class Landlord: public Person
{
public:
    void SetMediator(Mediator *mediator) { m_mediator = mediator; }
    void SendMessage(string message) { m_mediator->Send(message, this); }
    void GetMessage(string message) { cout<<"房东收到信息："<<message; }
};
//房屋中介
class HouseMediator : public Mediator
{
private:
    Person *m_A; //租房者
    Person *m_B; //房东
public:
    HouseMediator(): m_A(0), m_B(0) {}
    void SetA(Person *A) { m_A = A; }
    void SetB(Person *B) { m_B = B; }
    void Send(string message, Person *person)
    {
        if(person == m_A) //租房者给房东发信息
            m_B->GetMessage(message); //房东收到信息
        else
            m_A->GetMessage(message);
    }
};

//测试案例
int main()
{
    Mediator *mediator = new HouseMediator();
    Person *person1 = new Renter();    //租房者
    Person *person2 = new Landlord();  //房东
    mediator->SetA(person1);
    mediator->SetB(person2);
    person1->SetMediator(mediator);
    person2->SetMediator(mediator);
    person1->SendMessage("我想在南京路附近租套房子，价格800元一个月\n");
    person2->SendMessage("出租房子：南京路100号，70平米，1000元一个月\n");
    delete person1; delete person2; delete mediator;
    return 0;
}

16 职责链模式

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

职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无需关心请求的处理细节和请求的传递，所有职责链将请求的发送者和请求的处理者解耦了。

其思想很简单，考虑员工要求加薪。公司的管理者一共有三级，总经理、总监、经理，如果一个员工要求加薪，应该向主管的经理申请，如果加薪的数量在经理的职权内，那么经理可以直接批准，否则将申请上交给总监。总监的处理方式也一样，总经理可以处理所有请求。这就是典型的职责链模式，请求的处理形成了一条链，直到有一个对象处理请求。

#include <iostream>
#include <vector>

using namespace std;


//抽象管理者
class Manager
{
protected:
    Manager *m_manager;
    string m_name;
public:
    Manager(Manager *manager, string name):m_manager(manager), m_name(name){}
    virtual void DealWithRequest(string name, int num)  {}
};
//经理
class CommonManager: public Manager
{
public:
    CommonManager(Manager *manager, string name):Manager(manager,name) {}
    void DealWithRequest(string name, int num)
    {
        if(num < 500) //经理职权之内
        {
            cout<<"经理"<<m_name<<"批准"<<name<<"加薪"<<num<<"元"<<endl<<endl;
        }
        else
        {
            cout<<"经理"<<m_name<<"无法处理，交由总监处理"<<endl;
            m_manager->DealWithRequest(name, num);
        }
    }
};
//总监
class Majordomo: public Manager
{
public:
    Majordomo(Manager *manager, string name):Manager(manager,name) {}
    void DealWithRequest(string name, int num)
    {
        if(num < 1000) //总监职权之内
        {
            cout<<"总监"<<m_name<<"批准"<<name<<"加薪"<<num<<"元"<<endl<<endl;
        }
        else
        {
            cout<<"总监"<<m_name<<"无法处理，交由总经理处理"<<endl;
            m_manager->DealWithRequest(name, num);
        }
    }
};
//总经理
class GeneralManager: public Manager
{
public:
    GeneralManager(Manager *manager, string name):Manager(manager,name) {}
    void DealWithRequest(string name, int num)  //总经理可以处理所有请求
    {
        cout<<"总经理"<<m_name<<"批准"<<name<<"加薪"<<num<<"元"<<endl<<endl;
    }
};

//测试案例
int main()
{
    Manager *general = new GeneralManager(NULL, "A"); //设置上级，总经理没有上级
    Manager *majordomo = new Majordomo(general, "B"); //设置上级
    Manager *common = new CommonManager(majordomo, "C"); //设置上级
    common->DealWithRequest("D",300);   //员工D要求加薪
    common->DealWithRequest("E", 600);
    common->DealWithRequest("F", 1000);
    delete common; delete majordomo; delete general;
    return 0;
}

17 观察者模式

观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都要得到通知并自动更新。它还有两个别名，依赖(Dependents)，发布-订阅(Publish-Subsrcibe)。

观察者模式从根本上讲必须包含两个角色：观察者和被观察对象。

1. 被观察对象自身应该包含一个容器来存放观察者对象，当被观察者自身发生改变时通知容器内所有的观察者对象自动更新。
2. 观察者对象可以注册到被观察者的中，完成注册后可以检测被观察者的变化，接收被观察者的通知。当然观察者也可以被注销掉，停止对被观察者的监控。

可以举个博客订阅的例子，当博主发表新文章的时候，即博主状态发生了改变，那些订阅的读者就会收到通知，然后进行相应的动作，比如去看文章，或者收藏起来。博主与读者之间存在种一对多的依赖关系。
可以举个博客订阅的例子，当博主发表新文章的时候，即博主状态发生了改变，那些订阅的读者就会收到通知，然后进行相应的动作，比如去看文章，或者收藏起来。博主与读者之间存在种一对多的依赖关系。

#include <iostream>
#include <list>

using namespace std;

//观察者
class Observer
{
public:
    Observer() {}
    virtual ~Observer() {}
    virtual void Update() {}
};
//博客
class Blog
{
public:
    Blog() {}
    virtual ~Blog() {}
    void Attach(Observer *observer) { m_observers.push_back(observer); }	 //添加观察者
    void Remove(Observer *observer) { m_observers.remove(observer); }        //移除观察者
    void Notify() //通知观察者
    {
        list<Observer*>::iterator iter = m_observers.begin();
        for(; iter != m_observers.end(); iter++)
            (*iter)->Update();
    }
    virtual void SetStatus(string s) { m_status = s; } //设置状态
    virtual string GetStatus() { return m_status; }    //获得状态
private:
    list<Observer* > m_observers; //观察者链表
protected:
    string m_status; //状态
};


/*以上是观察者和博客的基类，定义了通用接口。博客类主要完成观察者的添加、移除、通知操作，设置和获得状态仅仅是一个默认实现。下面给出它们相应的子类实现。*/
//具体博客类
class BlogCSDN : public Blog
{
private:
    string m_name; //博主名称
public:
    BlogCSDN(string name): m_name(name) {}
    ~BlogCSDN() {}
    void SetStatus(string s) { m_status = "CSDN通知 : " + m_name + s; } //具体设置状态信息
    string GetStatus() { return m_status; }
};
//具体观察者
class ObserverBlog : public Observer
{
private:
    string m_name;  //观察者名称
    Blog *m_blog;   //观察的博客，当然以链表形式更好，就可以观察多个博客
public:
    ObserverBlog(string name,Blog *blog): m_name(name), m_blog(blog) {}
    ~ObserverBlog() {}
    void Update()  //获得更新状态
    {
        string status = m_blog->GetStatus();
        cout<<m_name<<"-------"<<status<<endl;
    }
};

//测试案例
int main()
{
    Blog *blog = new BlogCSDN("wuzhekai1985");
    Observer *observer1 = new ObserverBlog("tutupig", blog);
    blog->Attach(observer1);
    blog->SetStatus("发表设计模式C++实现（15）——观察者模式");
    blog->Notify();
    delete blog; delete observer1;
    return 0;
}

18 状态模式

状态模式：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

有两种使用情况：

1. 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
2. 一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。

本文的例子为第一种情况，以战争为例，假设一场战争需经历四个阶段：前期、中期、后期、结束。当战争处于不同的阶段，战争的行为是不一样的，也就说战争的行为取决于所处的阶段，而且随着时间的推进是动态变化的。

#include <iostream>

using namespace std;

class War;
class State
{
public:
    virtual void Prophase() {}
    virtual void Metaphase() {}
    virtual void Anaphase() {}
    virtual void End() {}
    virtual void CurrentState(War *war) {}
};

//战争
class War
{
private:
    State *m_state;  //目前状态
    int m_days;      //战争持续时间
public:
    War(State *state): m_state(state), m_days(0) {}
    ~War() { delete m_state; }
    int GetDays() { return m_days; }
    void SetDays(int days) { m_days = days; }
    void SetState(State *state) { delete m_state; m_state = state; }
    void GetState() { m_state->CurrentState(this); }
};

//战争结束
class EndState: public State
{
public:
    void End(War *war) //结束阶段的具体行为
    {
        cout<<"战争结束"<<endl;
    }
    void CurrentState(War *war) { End(war); }
};

//后期
class AnaphaseState: public State
{
public:
    void Anaphase(War *war) //后期的具体行为
    {
        if(war->GetDays() < 30)
            cout<<"第"<<war->GetDays()<<"天：战争后期，双方拼死一搏"<<endl;
        else
        {
            war->SetState(new EndState());
            war->GetState();
        }
    }
    void CurrentState(War *war) { Anaphase(war); }
};

//中期
class MetaphaseState: public State
{
public:
    void Metaphase(War *war) //中期的具体行为
    {
        if(war->GetDays() < 20)
            cout<<"第"<<war->GetDays()<<"天：战争中期，进入相持阶段，双发各有损耗"<<endl;
        else
        {
            war->SetState(new AnaphaseState());
            war->GetState();
        }
    }
    void CurrentState(War *war) { Metaphase(war); }
};

//前期
class ProphaseState: public State
{
public:
    void Prophase(War *war)  //前期的具体行为
    {
        if(war->GetDays() < 10)
            cout<<"第"<<war->GetDays()<<"天：战争初期，双方你来我往，互相试探对方"<<endl;
        else
        {
            war->SetState(new MetaphaseState());
            war->GetState();
        }
    }
    void CurrentState(War *war) { Prophase(war); }
};

//测试案例
int main()
{
    War *war = new War(new ProphaseState());
    for(int i = 1; i < 40;i += 5)
    {
        war->SetDays(i);
        war->GetState();
    }
    delete war;
    return 0;
}