行为变化模式
在组件的构建过程中,组件行为的变化经常导致组件本身剧烈的变化。行为变化模式将组件的行为和组件本身进行解耦,从而支持组件行为的变化,实现两者之间的松耦合
- 命令模式command
- 访问者模式visitor
1.命令模式command
动机: 在软件构建过程中,行为请求者与行为实现者通常呈现一种紧耦合。但在某些情况下——比如需要对行为进行记录、撤销/重(undo/redo)、事务等处理,这种无法抵御变化的紧耦合是不合适的
在这种情况下,如何将行为请求者与行为实现者解耦?将一组行为抽象为对象,可以实现二者之间的松耦合
#include <iostream>
#include <vector>
#include <string>
using namespace std;
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 process..."<<arg<<endl;
}
};
class ConcreteCommand2 : public Command
{
string arg;
public:
ConcreteCommand2(const string & a) : arg(a) {}
void execute() override
{
cout<< "#2 process..."<<arg<<endl;
}
};
//宏命令 组合模式
// 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()
{
ConcreteCommand1 command1(receiver, "Arg ###");
ConcreteCommand2 command2(receiver, "Arg $$$");
//命令组合
MacroCommand macro;
macro.addCommand(&command1);
macro.addCommand(&command2);
macro.execute();//多态调用
}
模式顶义 :将请求(行为)封装为一个对象,从而使你可用不同的请求对客户变化进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作(将行为实现为对象后,可以将行为对象放在vector/队列/栈中等 实现记录、排队、撤销操作等)

c++性能优先,用函数对象用的多,但是在其他java/c#等用的很多
要点总结:
- Command模式的根本目的在于将"行为请求者”与“行为实现者”解耦,在面向对象语言中,常见的实现手段是“将行为抽象为对象”。
- 实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式,可以将多个“命令”封装为一个“复合命令”MacroCommand .
- Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别: Command以面向对象中的“接口-实现"来定义行为接口规范,更严格,但有性能损失(虚函数); C++函数对象以函数签名来定义行为接口规范,更灵活,性能更高。(模板:编译时绑定 多态:运行时绑定)
设计模式是弥补语言不足才出现的?
2.访问者模式visitor
动机: 在软件构建过程中,由于某些需求的改变,某些类层次结构中常常需要增加新的方法,如果直接在基类中做这样的更改,将会给子类带来很繁重的变更负担,甚至破坏原有设计
如何在不更改类层次结构的前提下在运行时根据需要透明的为类层次结构上的各个类动态添加新的操作,从而避免上述问题?
#include <iostream>
using namespace std;
class Visitor;
class Element
{
public:
virtual void Func1() = 0;
//扩展func2 func3
virtual void Func2(int data)=0;
virtual void Func3(int data)=0;
//...
virtual ~Element(){}
};
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 {
//***
}
};
//在基类中添加了行为在派生类中都需要改
//visitor稳定的前提是element的所有子类需要稳定 条件苛刻
#include <iostream>
using namespace std;
//visitor模式 能预料到未来可能会为整个类结构层次添加操作 但是并不知道要加几个操作
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);
}
};
//visitor稳定的前提是element的所有子类需要稳定
//针对每一个子类写一个虚函数
class Visitor{
public:
virtual void visitElementA(ElementA& element) = 0;
virtual void visitElementB(ElementB& element) = 0;
virtual ~Visitor(){}
};
//==================================将来
//扩展1
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;
}
};
//扩展2
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);// double dispatch二次多态辨析/两次派遣
ElementA elementA;
elementA.accept(visitor);
return 0;
}
模式定义: 表示一个作用于某对象结构中的各元素的操作。使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这些元素的新操作(变化)

具体有几种element要确定 因为visitor依赖于concreteElement
如果新加一个子类 那么visitor需要改变 其派生类也都需要改变
可以变化的是visitor的子类 就是增加新的行为方法
要点总结:
- Visitor模式通过所谓双重分发(double dispatch)来实现在不更改(不添加新的操作-编译时)Element类层次结构的前提下,在运行时透明地为类层次结构上的各个类动态添加新的操作(支持变化)。
- 所谓双重分发即Visitor模式中间包括了两个多态分发(注意其中的多态机制)︰第一个为accept方法的多态辨析;第二个为visitElementX方法的多态辨析。
- Visitor模式的最大缺点在于扩展类层次结构(增添新的Element子类),会导致Visitor类的改变。因此Visitor模式适用于“Element类层次结构稳定,而其中的操作却经常面临频繁改动”。(有稳定有变化)
本文探讨了解耦组件行为与组件本身的两种设计模式:命令模式(command)和访问者模式(visitor)。命令模式通过将行为抽象为对象,实现行为请求者与行为实现者的松耦合。访问者模式则允许在不修改类层次结构的前提下,为类层次结构上的各个类动态添加新的操作。
1682

被折叠的 条评论
为什么被折叠?



