C++设计模式 | 四种行为型模式——模版方法模式、策略模式、命令模式、观察者模式

模版方法模式

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

AbstractClass（抽象类）：在抽象类中定义了一系列基本操作，这些基本操作可以是具体的，也可以是抽象的，每一个基本操作对应算法的一个步骤，在其子类中可以重定义或实现这些步骤。同时，在抽象类中实现了一个模板方法(Template Method)，用于定义一个算法的框架，模板方法不仅可以调用在抽象类中实现的基本方法，也可以调用在抽象类的子类中实现的基本方法，还可以调用其他对象中的方法。

ConcreteClass（具体子类）：它是抽象类的子类，用于实现在父类中声明的抽象基本操作以完成子类特定算法的步骤，也可以覆盖在父类中已经实现的具体基本操作。

#include
using namespace std;


class DrinkTemplate{
public:
    //煮水
    virtual void BoildWater() = 0;
    //冲泡
    virtual void Brew() = 0;
    //倒入杯中
    virtual void PourInCup() = 0;
    //加辅助料
    virtual void AddSomething() = 0;

    //模板方法
    void Make(){
        BoildWater();
        Brew();
        PourInCup();
        AddSomething();
    }
};

//冲泡咖啡
class Coffee : public DrinkTemplate{
public:
    virtual void BoildWater(){
        cout << "煮山泉水..." << endl;
    }
    //冲泡
    virtual void Brew(){
        cout << "冲泡咖啡..." << endl;
    }
    //倒入杯中
    virtual void PourInCup(){
        cout << "咖啡倒入杯中..." << endl;
    }
    //加辅助料
    virtual void AddSomething(){
        cout << "加糖，加牛奶,加点醋..." << endl;
    }
};

//冲泡茶水
class Tea : public DrinkTemplate{
public:
    virtual void BoildWater(){
        cout << "煮自来水..." << endl;
    }
    //冲泡
    virtual void Brew(){
        cout << "冲泡铁观音..." << endl;
    }
    //倒入杯中
    virtual void PourInCup(){
        cout << "茶水倒入杯中..." << endl;
    }
    //加辅助料
    virtual void AddSomething(){
        cout << "加糖..加柠檬...加生姜..." << endl;
    }
};

void test01(){

    Tea* tea = new Tea;
    tea->Make();

    cout << "-----------" << endl;

    Coffee* coffee = new Coffee;
    coffee->Make();
    
}


int main(){

    test01();

    return 0;
}

模板方法的优缺点及适用场景

优点：
(1)在父类中形式化地定义一个算法，而由它的子类来实现细节的处理，在子类实现详细的处理算法时并不会改变算法中步骤的执行次序。
(2)模板方法模式是一种代码复用技术，它在类库设计中尤为重要，它提取了类库中的公共行为，将公共行为放在父类中，而通过其子类来实现不同的行为，它鼓励我们恰当使用继承来实现代码复用。
(3)可实现一种反向控制结构，通过子类覆盖父类的钩子方法来决定某一特定步骤是否需要执行。
(4)在模板方法模式中可以通过子类来覆盖父类的基本方法，不同的子类可以提供基本方法的不同实现，更换和增加新的子类很方便，符合单一职责原则和开闭原则。

缺点：
需要为每一个基本方法的不同实现提供一个子类，如果父类中可变的基本方法太多，将会导致类的个数增加，系统更加庞大，设计也更加抽象。

适用场景：
(1)具有统一的操作步骤或操作过程;
(2) 具有不同的操作细节;
(3) 存在多个具有同样操作步骤的应用场景，但某些具体的操作细节却各不相同;

在抽象类中统一操作步骤，并规定好接口；让子类实现接口。这样可以把各个具体的子类和操作步骤解耦合。

策略模式

策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

Context（环境类）：环境类是使用算法的角色，它在解决某个问题（即实现某个方法）时可以采用多种策略。在环境类中维持一个对抽象策略类的引用实例，用于定义所采用的策略。
Strategy（抽象策略类）：它为所支持的算法声明了抽象方法，是所有策略类的父类，它可以是抽象类或具体类，也可以是接口。环境类通过抽象策略类中声明的方法在运行时调用具体策略类中实现的算法。
ConcreteStrategy（具体策略类）：它实现了在抽象策略类中声明的算法，在运行时，具体策略类将覆盖在环境类中定义的抽象策略类对象，使用一种具体的算法实现某个业务处理。

#define _CRT_SECURE_NO_WARNINGS
#include 
using namespace std;


//抽象武器 武器策略
class WeaponStrategy{
public:
    virtual void UseWeapon() = 0;
};

class Knife : public WeaponStrategy{
public:
    virtual void UseWeapon(){
        cout << "使用匕首！" << endl;
    }
};

class AK47 :public WeaponStrategy{
public:
    virtual void UseWeapon(){
        cout << "使用AK47！" << endl;
    }
};

class Character {
public:
    void setWeapon(WeaponStrategy* weapon){
        this->pWeapon = weapon;
    }
    void ThrowWeapon(){
        this->pWeapon->UseWeapon();
    }
public:
    WeaponStrategy* pWeapon;
};


void test01(){
    
    //创建角色
    Character* character = new Character;

    //武器策略
    WeaponStrategy* knife = new Knife;
    WeaponStrategy* ak47 = new AK47;

    character->setWeapon(knife);
    character->ThrowWeapon();

    character->setWeapon(ak47);
    character->ThrowWeapon();

    delete ak47;
    delete knife;
    delete character;
}

int main(void){

    test01();
    
    return 0;
}

策略模式的优缺点及适用场景

优点：
(1)策略模式提供了对“开闭原则”的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
(2)使用策略模式可以避免多重条件选择语句。多重条件选择语句不易维护，它把采取哪一种算法或行为的逻辑与算法或行为本身的实现逻辑混合在一起，将它们全部硬编码(Hard Coding)在一个庞大的多重条件选择语句中，比直接继承环境类的办法还要原始和落后。
(3)策略模式提供了一种算法的复用机制。由于将算法单独提取出来封装在策略类中，因此不同的环境类可以方便地复用这些策略类。

缺点：
(1)客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
(2)策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。

适用场景：
准备一组算法，并将每一个算法封装起来，使得它们可以互换。

命令模式

    将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。
命令模式可以将请求发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。

Command（抽象命令类）：抽象命令类一般是一个抽象类或接口，在其中声明了用于执行请求的execute()等方法，通过这些方法可以调用请求接收者的相关操作。

ConcreteCommand（具体命令类）：具体命令类是抽象命令类的子类，实现了在抽象命令类中声明的方法，它对应具体的接收者对象，将接收者对象的动作绑定其中。在实现execute()方法时，将调用接收者对象的相关操作(Action)。

Invoker（调用者）：调用者即请求发送者，它通过命令对象来执行请求。一个调用者并不需要在设计时确定其接收者，因此它只与抽象命令类之间存在关联关系。在程序运行时可以将一个具体命令对象注入其中，再调用具体命令对象的execute()方法，从而实现间接调用请求接收者的相关操作。

Receiver（接收者）：接收者执行与请求相关的操作，它具体实现对请求的业务处理。

#define _CRT_SECURE_NO_WARNINGS
#include 
#include

using namespace std;


//协议处理类
class HandleClientProtocol{
public:
    //处理增加金币
    void AddMoney(){
        cout << "给玩家增加金币！" << endl;
    }

    //处理增加钻石
    void AddDiamond(){
        cout << "给玩家增加钻石!" << endl;
    }

    //处理玩家装备
    void AddEquipment(){
        cout << "给玩家穿装备！" << endl;
    }

    //处理玩家升级
    void addLevel(){
        cout << "给玩家升级!" << endl;
    }
};

//命令接口
class AbstractCommand{
public:
    virtual void handle() = 0; //处理客户端请求的接口
};


//处理增加金币请求
class AddMoneyCommand :public AbstractCommand{
public:
    AddMoneyCommand(HandleClientProtocol* protocol){
        this->pProtocol = protocol;
    }
    virtual void handle(){
        this->pProtocol->AddMoney();
    }
public:
    HandleClientProtocol* pProtocol;
};

//处理增加钻石的请求
class AddDiamondCommand :public AbstractCommand{
public:
    AddDiamondCommand(HandleClientProtocol* protocol){
        this->pProtocol = protocol;
    }
    virtual void handle(){
        this->pProtocol->AddDiamond();
    }
public:
    HandleClientProtocol* pProtocol;
};


//处理玩家穿装备的请求
class AddEquipmentCommand : public AbstractCommand{
public:
    AddEquipmentCommand(HandleClientProtocol* protocol){
        this->pProtocol = protocol;
    }
    virtual void handle(){
        this->pProtocol->AddEquipment();
    }
public:
    HandleClientProtocol* pProtocol;
};

//处理玩家升级的请求
class AddLevelCommand : public AbstractCommand{
public:
    AddLevelCommand(HandleClientProtocol* protocol){
        this->pProtocol = protocol;
    }
    virtual void handle(){
        this->pProtocol->addLevel();
    }
public:
    HandleClientProtocol* pProtocol;

};


//服务器程序
class Serser{
public:
    void addRequest(AbstractCommand* command){
        mCommands.push(command);
    }

    void startHandle(){
        while (!mCommands.empty()){

            AbstractCommand* command = mCommands.front();
            command->handle();
            mCommands.pop();
        }
    }
public:
    queue mCommands;
};

void test01(){
    
    HandleClientProtocol* protocol = new HandleClientProtocol;
    //客户端增加金币的请求
    AbstractCommand* addmoney = new AddMoneyCommand(protocol);
    //客户端增加钻石的请求
    AbstractCommand* adddiamond = new AddDiamondCommand(protocol);
    //客户端穿装备的请求
    AbstractCommand* addequpment = new AddEquipmentCommand(protocol);
    //客户端升级请求
    AbstractCommand* addlevel = new AddLevelCommand(protocol);

    Serser* server = new Serser;
    //将客户端请求加入到处理的队列中
    server->addRequest(addmoney);
    server->addRequest(adddiamond);
    server->addRequest(addequpment);
    server->addRequest(addlevel);

    //服务器开始处理请求
    server->startHandle();
}

int main(void){
    test01();
    return 0;
}

命令模式的优缺点及适用场景

优点：
(1)降低系统的耦合度。由于请求者与接收者之间不存在直接引用，因此请求者与接收者之间实现完全解耦，相同的请求者可以对应不同的接收者，同样，相同的接收者也可以供不同的请求者使用，两者之间具有良好的独立性。
(2)新的命令可以很容易地加入到系统中。由于增加新的具体命令类不会影响到其他类，因此增加新的具体命令类很容易，无须修改原有系统源代码，甚至客户类代码，满足“开闭原则”的要求。
(3)可以比较容易地设计一个命令队列或宏命令（组合命令）。

缺点：
使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调用操作都需要设计一个具体命令类，因此在某些系统中可能需要提供大量的具体命令类，这将影响命令模式的使用。

适用场景：
(1) 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。
(2) 系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调用者可以有不同的生命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍然是活动的，可以通过该命令对象去调用请求接收者，而无须关心请求调用者的存在性，可以通过请求日志文件等机制来具体实现。
(3) 系统需要将一组操作组合在一起形成宏命令。

观察者模式

观察者模式是用于建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应作出反应。在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间可以没有任何相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。

Subject（被观察者或目标，抽象主题）：被观察的对象。当需要被观察的状态发生变化时，需要通知队列中所有观察者对象。Subject需要维持（添加，删除，通知）一个观察者对象的队列列表。
ConcreteSubject（具体被观察者或目标，具体主题）：被观察者的具体实现。包含一些基本的属性状态及其他操作。
Observer（观察者）：接口或抽象类。当Subject的状态发生变化时，Observer对象将通过一个callback函数得到通知。
ConcreteObserver（具体观察者）：观察者的具体实现。得到通知后将完成一些具体的业务逻辑处理。

#define _CRT_SECURE_NO_WARNINGS
#include 
#include
using namespace std;

//抽象的英雄 抽象的观察者
class AbstractHero{
public:
    virtual void Update() = 0;
};


//具体英雄  具体观察者
class HeroA :public AbstractHero{
public:
    HeroA(){
        cout << "英雄A正在撸BOSS ..." << endl;
    }
    virtual void Update(){
        cout << "英雄A停止撸,待机状态..." << endl;
    }
};

class HeroB :public AbstractHero{
public:
    HeroB(){
        cout << "英雄B正在撸BOSS ..." << endl;
    }
    virtual void Update(){
        cout << "英雄B停止撸,待机状态..." << endl;
    }
};

class HeroC :public AbstractHero{
public:
    HeroC(){
        cout << "英雄C正在撸BOSS ..." << endl;
    }
    virtual void Update(){
        cout << "英雄C停止撸,待机状态..." << endl;
    }
};

class HeroD :public AbstractHero{
public:
    HeroD(){
        cout << "英雄D正在撸BOSS ..." << endl;
    }
    virtual void Update(){
        cout << "英雄D停止撸,待机状态..." << endl;
    }
};

class HeroE :public AbstractHero{
public:
    HeroE(){
        cout << "英雄E正在撸BOSS ..." << endl;
    }
    virtual void Update(){
        cout << "英雄E停止撸,待机状态..." << endl;
    }
};


//观察目标抽象
class AbstractBoss{
public:
    //添加观察者
    virtual void addHero(AbstractHero* hero) = 0;
    //删除观察者
    virtual void deleteHero(AbstractHero* hero) = 0;
    //通知所有观察者
    virtual void notify() = 0; 
};


//具体的观察者 BOSSA
class BOSSA : public AbstractBoss{
public:
    virtual void addHero(AbstractHero* hero){
        pHeroList.push_back(hero);
    }
    //删除观察者
    virtual void deleteHero(AbstractHero* hero){
        pHeroList.remove(hero);
    }
    //通知所有观察者
    virtual void notify(){
        for (list::iterator it = pHeroList.begin(); it != pHeroList.end();it ++){
            (*it)->Update();
        }
    }
public:
    list pHeroList;
};



void test01(){
    

    //创建观察者
    AbstractHero* heroA = new HeroA;
    AbstractHero* heroB = new HeroB;
    AbstractHero* heroC = new HeroC;
    AbstractHero* heroD = new HeroD;
    AbstractHero* heroE = new HeroE;

    //创建观察目标
    AbstractBoss* bossA = new BOSSA;
    bossA->addHero(heroA);
    bossA->addHero(heroB);
    bossA->addHero(heroC);
    bossA->addHero(heroD);
    bossA->addHero(heroE);


    cout << "heroC阵亡..." << endl;
    bossA->deleteHero(heroC);

    cout << "Boss死了...通知其他英雄停止攻击，抢装备..." << endl;
    bossA->notify();

}


int main(void){
    test01();
    return 0;
}

观察者模式的优缺点及适用场景

优点：
(1)观察者模式可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制，并抽象了更新接口，使得可以有各种各样不同的表示层充当具体观察者角色。
(2)观察者模式在观察目标和观察者之间建立一个抽象的耦合。观察目标只需要维持一个抽象观察者的集合，无须了解其具体观察者。由于观察目标和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
(3)观察者模式支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一对多系统设计的难度。
(4)观察者模式满足“开闭原则”的要求，增加新的具体观察者无须修改原有系统代码，在具体观察者与观察目标之间不存在关联关系的情况下，增加新的观察目标也很方便。

缺点：
(1)如果一个观察目标对象有很多直接和间接观察者，将所有的观察者都通知到会花费很多时间。
(2)观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

适用场景：
(1)一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两个方面封装在独立的对象中使它们可以各自独立地改变和复用。
(2)一个对象的改变将导致一个或多个其他对象也发生改变，而并不知道具体有多少对象将发生改变，也不知道这些对象是谁。
(3)需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。