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

命令模式（Command）

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

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

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

class ConcreteCommand01 : public Command{
    string arg;
public:
    ConcreteCommand01(const string &a) : arg(a){}
    void execute() override{
        // 执行
    }
};

class ConcreteCommand02 : public Command{
    string arg;
public:
    ConcreteCommand01(const string &a) : arg(a){}
    void execute() override{
        // 执行
    }
};

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

int main(){// 其本质就是将一些行为（函数）当成对象用，可以随意组合、存在容器里、记录。
    ConcreteCommand01 command01("Command1");
    ConcreteCommand02 command02("Command2");

    MacroCommand macro;
    macro.addCommand(&command01);
    macro.addCommand(&command02);

    macro.execute();

    return 0;
}

• 其本质就是将一些行为（函数）当成对象用，可以随意组合、存在容器里、记录。
• 但是，上述实现是使用虚函数，面向对象的方式解决，而C++11后，有很多方式起到类似作用，比如函数对象（在类里重载圆括号、lambda、std::function、std::bind），函数对象可以拥有自己的成员（或某种方式实现状态存储）。

要点总结：
– Command模式根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言种，常见的实现手段是“将行为抽象为对象”
– 实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令”封装为一个复合命令

访问器（Visitor）

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

反面样例：

class Element{
public:
    virtual void Func1() = 0;
    virtual ~Element() {}
};

class ElementA : public Element{
public:
    void Func1() override{
        // ...
    } 
};

class ElementB : public Element{
public:
    void Func1() override{
        // ...
    } 
};

当像上面这样写时，如果基类Element要增加一个新的行为（函数），那么所有的子类的都要跟着增加，并且是在原代码的基础上修改，违背了对修改封闭的原则。

故有下述写法

class Visitor;

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

class ElementA : public Element{
public:
    void accept(Vistor &vis) override {
        vis.visitElementA(*this);
    }
};

class ElementB : public Element{
public:
    void accept(Vistor &vis) override {
        vis.visitElementB(*this);
    }
};

class Visitor{
public:
    virtual void visitElementA(ElementA &elem) = 0;
    virtual void visitElementB(ElementA &elem) = 0;
    virtual ~Visitor() {}
};

class Visitor1 : public Visitor{ // 行为1，（比如他可以实现的是步枪射击）
public:
    void visitElementA(ElementA &elem) override{
        // ...
    }
    void visitElementB(ElementB &elem) override{
        // ...
    }
}

class Visitor2 : public Visitor{ // 新行为2   （又可以新增霰弹射击）
public:
    void visitElementA(ElementA &elem) override{
        // ...
    }
    void visitElementB(ElementB &elem) override{
        // ...
    }
}

int main(){
    Visitor2 vis2;
    ElementB *elementB;
    // elementB.accept(vis2);// 为B调用了行为2的功能
    ElementA *elementA;

    vector<Element*> arr{elementA, elementB};
    for(auto &ele:arr){
        arr->accept(vis2); // 为A和B都调用了行为2
    }

    Visitor1 vis1;
    for(auto &ele:arr){
        arr->accept(vis1); // 为A和B都调用了行为1
    }

    return 0;
}

但是该模式最大的一个缺点就是，Element的子类数量应该是确定的，不然Visitor类的虚函数的数量就会根据Element的子类数量变化，那么Visitor的子类也会变化，违背了，开闭原则

要点总结：
– Visitor模式通过所谓双重分发（double dispatch，accept和visitElement都是虚函数）来实现在不更改（不添加新的操作——编译时）Element类层次结构的前提下，在运行时透明地为类层次结构的各个类动态添加新的操作（支持变化）
– 所谓双重分发，即Visitor模式中间包括了两个多态分发（accept和visitElement）
– Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于“Element层次结构稳定，而其中操作却经常面临更改