设计模式-Note9-行为变化类

Command

命令模式

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

解决什么问题

在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行”记录、撤销/重做（undo/redo）、事务“等处理，这种无法抵御变化的紧耦合是不合适的。

在这种情况下，如何将“行为请求者”与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

结构

要点总结

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

示例

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

class ConcreteCommand1 : public Command {
private:
    string arg;
public:
    ConcreteCommand1(const string& a) : arg(a) {}
    void execute() override {
        // ...
    }
};

class ConcreteCommand2 : public Command {
private:
    string arg;
public:
    ConcreteCommand2(const string& a) : arg(a) {}
    void execute() override {
        // ...
    }
};

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

void process() {
    ConcreteCommand1 command1(receiver, "...");
    ConcreteCommand2 command2(receiver, "...");

    MacroCommand macro;
    macro.addCommand(&command1);
    macro.addCommand(&command2);

    macro.execute();
}

Visitor

访问器

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

解决什么问题

在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有的设计。

如何在不改变类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题。

结构

要点总结

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

示例

class Element {
public:
    virtual ~Element() {}

    virtual void Func1() = 0;
    virtual void Func2(int data) = 0;
};

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

    void Func2(int data) override {
        // ...
    }
};

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

    void Func2(int data) override {
        // ...
    }
};

// 需要添加一个新功能 Func2
// 在基类添加接口 并在各个子类添加对应接口的实现

// 采用Visitor模式
// 稳定
class Visitor {
public:
    virtual ~Visitor() {}

    virtual void visitElementA(ElementA& element) = 0;
    virtual void visitElementB(ElementB& element) = 0;
};

class Element {
public:
    virtual ~Element() {}

    virtual void accept(Visitor& visitor) = 0;
};

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 Visitor1 : public Visitor {
public:
    void visitElementA(ElementA& element) override {
        // ...
    }

    void visitElementB(ElementB& element) override {
        // ...
    }
}

// 需要对Element添加新功能 Func2时
class Visitor2 : public Visitor {
public:
    void visitElementA(ElementA& element) override {
        // ...
    }

    void visitElementB(ElementB& element) override {
        // ...
    }
}

void Process() {
    Visitor2 visitor;
    ElementB element;
    element.accept(visitor);// 相当于elementB.Func2()

    return 0;
}