一、对象性能模式
该模式的产生背景：
面向对象很好的解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。
其典型设计模式包括：
<1>单件模式Singleton
<2>享元模式Flyweight
（1）单件模式Singleton
动机：
在软件系统中，经常有这样一个特殊的类，必须保证它们在系统中只存在一个示例，才能确保他们的逻辑正确性以及良好的效率。
如何保证一个类只有一个实例，这个应该类设计者的责任，而不是使用者的责任。
定义：
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
为了能够保证绕开常规构造器，其类的构造有所不同：
class Singleton{
private:
Singleton();
Singleton(const Singleton& other);
public:
static Singleton* getInstance();
static Singleton* m_instance;
};
Singleton* Singleton::m_instance=nullptr;
在上述代码中，类的构造函数和拷贝构造函数被赋予了private权限，同时定义了静态变量m_instance和静态函数getInstance()。
<1>线程非安全版本
Singleton* Singleton::getInstance() {
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
上述代码在单线程下时没有问题的，但是在多线程情况下会出现问题。
假设此时存在两个线程1和线程2。当线程1执行到 if (m_instance == nullptr) 时，线程2刚好取得了CPU时间片，此时执行线程2.由于此时对于两个线程而言，m_instance == nullptr均成立，那么就会创建两个实例。不符合单件模式的要求。
<2>线程安全版本
Singleton* Singleton::getInstance() {
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
可以通过上述进程锁的方式解决上述线程非安全版本所潜在的问题。当线程1开始执行时，会添加一个进程锁。该进程锁只有在线程1完全执行完毕之后才会解除，因此即使线程2在线程1执行过程中取得了CPU时间片，线程2也执行实例的创建。
但是这种类型的机制也存在一定的缺陷，那就是这会造成代码的执行效率过低。一旦产生一个线程锁，另外的线程必须等待解锁之后，才能利用getInstance获取对象。如果应用于高并发的应用中，这将会大大拖累执行效率。
<3>双检查锁
Singleton* Singleton::getInstance() {
if(m_instance==nullptr){
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
}
return m_instance;
}
在双检查锁代码中，只有在创建时才会生成一个线程锁。这样就能够避免在读取时每次都会创建一个锁。在这样的代码中必须进行两次判空处理。
但是双检查锁在内存读写时会出现reorder状态下出错的缺陷。
在进行m_instance = new Singleton()处理时，我们期望的顺序是：首先分配内存；再调用构造函数创建对象；再将对象的地址赋值给变量。
但是在实际执行中，上述顺序将会被打乱。
这时可能就变成：首先分配内存；再将对象的地址赋值给变量；再调用构造函数创建对象。
这时变量已经被赋值了对象的指针，但是实际却指向了没有被初始化的内存。
<4>C++ 11版本之后的跨平台实现 (volatile)
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
//首先声明了一个原子的对象
Singleton* tmp = m_instance.load(std::memory_order_relaxed);
std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
std::atomic_thread_fence(std::memory_order_release);//释放内存fence
m_instance.store(tmp, std::memory_order_relaxed);
}
}
return tmp;
}
单件模式要点总结：
<1> Singleton模式中的实例构造器可以设置为protected，以允许子类派生。
<2> Singleton模式一般不要支持拷贝构造函数和Clone接口，因为有可能会导致多个对象实例，与Singleton模式的初衷相违背。
<3>如何实现多线程环境下安全的Singleton？注意对双检查锁的正确实现。
（2）享元模式Flyweight
动机：
在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行是代价——主要指内存需求方面的代价。
定义：
运用共享技术有效地支持大量的细粒度对象。
享元模式会设置一个对象池。当需要某种已经存在的对象时，此时只需从对象池中将对象取出即可，这样就将对象的创建变更为对象的取用，避免了每次都需要创建新的对象。
class Font {
private:
//unique object key
string key;
//object state
//....
public:
Font(const string& key){
//...
}
};
class FontFactory{
private:
map<string,Font* > fontPool;
public:
Font* GetFont(const string& key){
// 通过key在字体池中查找字体对象
map<string,Font*>::iterator item=fontPool.find(key);
if(item!=footPool.end()){
// 返回查找到的字体
return fontPool[key];
}
else{
// 创建一种字体池中不存在的字体对象
Font* font = new Font(key);
fontPool[key]= font;
return font;
}
}
void clear(){
//...
}
};
在上述代码中创建了字体池FontFactory，通过key在字体池中查找所需要的字体，这样就避免了字体的频繁创建。FlyWeight共享的对象一旦创建则无法改变，所以该对象应该是只读的。
要点总结：
<1>面向对象很好的解决了抽相性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向的代价问题，一般不触及面向对象的抽象性问题。
<2> Flyweight采用对象共享的做法来降低系统中的对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对像状态的处理。
<3>对象的数量太大，从而导致对像内存开销加大——什么样的数量才算大？这需要我们仔细根据具体应用情况进行评估，而不能凭空臆断。
二、状态变化模式
产生动机：
在组建构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一个问题提供了一种解决方案。
其典型设计模式：
<1>状态模式State
<2>备忘录Memento
（1）状态模式State
动机：
在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能会完全不同。
定义：
允许一个对象在其内部状态改变是改变它的行为。从而使对像看起来似乎修改其行为。
下例表示一个网络应用逻辑，其中包括打开、关闭和连接三种操作，并且不同的状态会引发不同的操作。每一次操作完成之后，其状态也会随之变化。
enum NetworkState
{
Network_Open,
Network_Close,
Network_Connect,
};
class NetworkProcessor{
NetworkState state;
public:
void Operation1(){
if (state == Network_Open){
//**********
state = Network_Close;
}
else if (state == Network_Close){
//..........
state = Network_Connect;
}
else if (state == Network_Connect){
//$$$$$$$$$$
state = Network_Open;
}
}
public void Operation2(){
if (state == Network_Open){
//**********
state = Network_Connect;
}
else if (state == Network_Close){
//.....
state = Network_Open;
}
else if (state == Network_Connect){
//$$$$$$$$$$
state = Network_Close;
}
}
public void Operation3(){
••••••
}
};
在上述代码中通过一系列if-elseif-else来进行状态判断，进而进行操作方式的选择。若出现新的变化，那么之后的代码都需要进行改变。
与策略模式相似，对状态实行向上抽象。将所有与状态相关的操作变成每一个具体状态对象的行为。在每一个状态对象的操作执行完成之后，将会自动定义下一个状态。对于调用者来说，每次的状态改变只需要将指针指向操作所改变的下一个对象即可，完全不需要考虑下一个状态是什么。
class NetworkState{
public:
NetworkState* pNext;
virtual void Operation1()=0;
virtual void Operation2()=0;
virtual void Operation3()=0;
virtual ~NetworkState(){}
};
class OpenState :public NetworkState{
// 使用单件模式
static NetworkState* m_instance;
public:
static NetworkState* getInstance(){
if (m_instance == nullptr) {
m_instance = new OpenState();
}
return m_instance;
}
void Operation1(){
//**********
pNext = CloseState::getInstance();
}
void Operation2(){
//..........
pNext = ConnectState::getInstance();
}
void Operation3(){
//$$$$$$$$$$
pNext = OpenState::getInstance();
}
};
class CloseState:public NetworkState{ ••••••}
class NetworkProcessor{
NetworkState* pState;
public:
NetworkProcessor(NetworkState* pState){
this->pState = pState;
}
void Operation1(){
//...
pState->Operation1();
pState = pState->pNext;
//...
}
void Operation2(){
//...
pState->Operation2();
pState = pState->pNext;
//...
}
void Operation3(){
//...
pState->Operation3();
pState = pState->pNext;
//...
}
};
要点总结：
<1> State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对像状态切换时， 切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
<2>为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
<3>如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。
（2）备忘录Memento
动机：
在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需求，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有借口来让其它对象得到对象的状态，便会暴露对象的实现细节。
定义：
在不破坏封装性的前提下，不活一个对象的内部状态，并在该对像之外保存这个状态。这样以后就可以将该对像恢复到原想保存的状态。
class Memento
{
string state;
//..
public:
Memento(const string & s) : state(s) {}
string getState() const { return state; }
void setState(const string & s) { state = s; }
};
class Originator
{
string state;
//....
public:
Originator() {}
Memento createMomento() {
Memento m(state);
return m;
}
void setMomento(const Memento & m) {
state = m.getState();
}
};
int main()
{
Originator orginator;
//捕获对象状态，存储到备忘录
Memento mem = orginator.createMomento();
//... 改变orginator状态
//从备忘录中恢复
orginator.setMomento(memento);
}
在上例中Originator是一个需要被保存的对象，该对象中可能会存在多种状态。为了保证其封装性，所设计的Memento对象提供了对外开放的接口。
以上仅仅是一个示意性的伪码描述，也可以通过其他的手段来实现Memento的过程，比如对象的序列化和反序列化等等。
要点总结：
<1>备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原发器的状态。
<2> Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但同时又需要将其状态保持到外界（Memento）。
<3>由于现代语言运行时（如C#、java等）都具有相当的对象序列化支持，因此往往采用效率较高、有较容易正确实现的序列化方案来实现Memento模式。
三、数据结构模式
产生动机：
常常有一些组建在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大的破坏组件的复用。这时候，将这些数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。
其典型设计模式：
<1>组合模式Composite
<2>迭代器iterator
<3>责任链Chain of Responsibility
（1）组合模式Composite
动机：
在某些软件中，客户代码过多地依赖于对像容器复杂的内部实现结构，对像容器内部实现结构（而非抽象接口）的变化将因其客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。
定义：
将对象组合成树形结构以表示“部分-整体”的层级结构。Compisite使得用户对单个对象和组合对象的使用具有一致性（稳定）。
class Component
{
public:
virtual void process() = 0;
virtual ~Component(){}
};
//树节点
class Composite : public Component{
string name;
list<Component*> elements; // 子节点
public:
Composite(const string & s) : name(s) {}
void add(Component* element) {
elements.push_back(element);
}
void remove(Component* element){
elements.remove(element);
}
void process(){
// 以下为关键部分
//1. process current node处理当前节点
//2. process leaf nodes处理叶子节点
for (auto &e : elements)
e->process(); //多态调用
}
};
//叶子节点
class Leaf : public Component{
string name;
public:
Leaf(string s) : name(s) {}
void process(){
//process current node
}
};
void Invoke(Component & c){
//...
c.process(); // 多态调用
//...
}
int main()
{
Composite root("root");
Composite treeNode1("treeNode1");
Composite treeNode2("treeNode2");
Composite treeNode3("treeNode3");
Composite treeNode4("treeNode4");
Leaf leat1("left1");
Leaf leat2("left2");
root.add(&treeNode1);
treeNode1.add(&treeNode2);
treeNode2.add(&leaf1);
root.add(&treeNode3);
treeNode3.add(&treeNode4);
treeNode4.add(&leaf2);
process(root);
process(leaf2);
process(treeNode3);
}
要点总结：
<1> Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地（复用）处理对象和对象容器，无需关心处理的是单个对象还是组合的对象容器。
<2>将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的内部实现结构——发生依赖，从而更能“应对变化”。
<3> Composite模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。
（2）迭代器Iterator
动机：
在软件构建过程中，集合对象内部结构常常变化各异。但由于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。
使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“因对变化中的集合对象”提供了一种优雅的方式。
定义：
提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露（隔离变化，稳定）该对象的内部表示。
template<typename T>
class Iterator
{
public:
virtual void first() = 0;
virtual void next() = 0;
virtual bool isDone() const = 0;
virtual T& current() = 0;
};
template<typename T>
class MyCollection{
public:
Iterator<T> GetIterator(){
//...
}
};
template<typename T>
class CollectionIterator : public Iterator<T>{
MyCollection<T> mc;
public:
CollectionIterator(const MyCollection<T> & c): mc(c){ }
void first() override {
}
void next() override {
}
bool isDone() const override{
}
T& current() override{
}
};
void MyAlgorithm()
{
MyCollection<int> mc;
Iterator<int> iter= mc.GetIterator();
for (iter.first(); !iter.isDone(); iter.next()){
cout << iter.current() << endl;
}
}
在面向对象的模式迭代器代码中，其操作全部是虚函数。面向对象的虚函数调用是会造成一定的性能成本的。在进行遍历过程中需要反复调用上述虚函数，这也将造成性能成本的大幅增加。面向对象的迭代器相对于基于泛型编程的模板编程方法，其性能是前者优于后者。
要点总结：
<1>迭代抽象：访问一个聚合对象的内容而无需暴露其内部表示。
<2>迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。
<3>迭代器健壮性考虑：便利的同时更改迭代器所在的集合结构，会导致问题。
（3）责任链 Chain of Resposibility
动机：
在软件构建的过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。
定义：
使多个对像都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对像连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
enum class RequestType
{
REQ_HANDLER1,
REQ_HANDLER2,
REQ_HANDLER3
};
class Reqest
{
// 请求信息
string description;
RequestType reqType;
public:
Reqest(const string & desc, RequestType type) : description(desc), reqType(type) {}
RequestType getReqType() const { return reqType; }
const string& getDescription() const { return description; }
};
class ChainHandler{
// 链式结构
ChainHandler *nextChain;
void sendReqestToNextHandler(const Reqest & req)
{
if (nextChain != nullptr)
nextChain->handle(req);
}
protected:
// 判断请求是否能够被处理
virtual bool canHandleRequest(const Reqest & req) = 0;
// 处理请求
virtual void processRequest(const Reqest & req) = 0;
public:
ChainHandler() { nextChain = nullptr; }
void setNextChain(ChainHandler *next) { nextChain = next; }
void handle(const Reqest & req)
{
// 处理请求
if (canHandleRequest(req))
processRequest(req);
else
sendReqestToNextHandler(req);
}
};
class Handler1 : public ChainHandler{
protected:
bool canHandleRequest(const Reqest & req) override
{
return req.getReqType() == RequestType::REQ_HANDLER1;
}
void processRequest(const Reqest & req) override
{
cout << "Handler1 is handle reqest: " << req.getDescription() << endl;
}
};
class Handler2 : public ChainHandler{
protected:
bool canHandleRequest(const Reqest & req) override
{
return req.getReqType() == RequestType::REQ_HANDLER2;
}
void processRequest(const Reqest & req) override
{
cout << "Handler2 is handle reqest: " << req.getDescription() << endl;
}
};
class Handler3 : public ChainHandler{
protected:
bool canHandleRequest(const Reqest & req) override
{
return req.getReqType() == RequestType::REQ_HANDLER3;
}
void processRequest(const Reqest & req) override
{
cout << "Handler3 is handle reqest: " << req.getDescription() << endl;
}
};
int main(){
Handler1 h1;
Handler2 h2;
Handler3 h3;
h1.setNextChain(&h2);
h2.setNextChain(&h3);
Reqest req("process task ... ", RequestType::REQ_HANDLER3);
h1.handle(req);
return 0;
}
要点总结：
<1> Chain of Responsibility模式的应用场合在于“一个请求可能有多个接受者，但是最后真正接受者只有一个”，这时候请求发送者与接受者的耦合可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好的应对变化。
<2>应用了Chain of Responsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。
<3>如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。
四、行为变化模式
产生动机：
在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。
其典型设计模式：
<1>命令模式Command
<2>访问者Visitor
（1）命令模式Command
动机：
在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销（undo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
定义：
将一个请求（行为）封装为对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
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();
}
在Command类中存在一个execute的虚函数，并以此派生出一系列子类型。可以通过一些容器的存放对象的模式，来实现出类似于剪切、撤销等操作，只需要将对象弹出或者压入即可。
要点总结：
<1> Command模式的根本目的在于“行为请求者”与“行为实现者”解耦，在面向对象的语言中，常见的实现手段是“将行为抽象为对象”。
<2>实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite组合模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。
<3> Command模式与C++中的函数对像有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，但有性能损失；C++函数对象以函数签名来定义行为接口规范，更灵活，性能能高。
（2）访问者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); //第二次多态辨析
}
};
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;
}
当父类发生改变时，其所派生出的所有子类都需要进行修改，这样的修改代价过高，有违与开闭原则。
class Element
{
public:
virtual void Func1() = 0;
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 {
//***
}
};
要点总结：
<1> Vistor模式通过所谓的双重分发（double dispatch）来实现在不更改（不添加新的操作-编译时）Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作（支持变化）。
<2>所谓双重分发即Vistor模式中包括了两个多态分发（注意其中的多态机制）：第一个accept方法的多态解析；第二个visitElementX方法的多态解析。
<3> Visitor模式最大的缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于“Element类层次结构稳定，而其中的操作却经常面临频繁改动”。
五、领域规则模式
在特定领域内，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出该领域下的一般性解决方案。
其典型模式：解析器Interpreter
（1）解析器Interpreter
动机：
在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断的重复出现，如果使用普通的变成方式来实现将面临非常频繁的变化。
定义：
给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。
以下为一个关于字符串类型表达式的解析代码：
class Expression {
public:
virtual int interpreter(map<char, int> var)=0;
virtual ~Expression(){}
};
//变量表达式
class VarExpression: public Expression {
char key;
public:
VarExpression(const char& key)
{
this->key = key;
}
int interpreter(map<char, int> var) override {
return var[key];
}
};
//符号表达式
class SymbolExpression : public Expression {
// 运算符左右两个参数
protected:
Expression* left;
Expression* right;
public:
SymbolExpression( Expression* left, Expression* right):
left(left),right(right){
}
};
//加法运算
class AddExpression : public SymbolExpression {
public:
AddExpression(Expression* left, Expression* right):
SymbolExpression(left,right){
}
int interpreter(map<char, int> var) override {
return left->interpreter(var) + right->interpreter(var);
}
};
//减法运算
class SubExpression : public SymbolExpression {
public:
SubExpression(Expression* left, Expression* right):
SymbolExpression(left,right){
}
int interpreter(map<char, int> var) override {
return left->interpreter(var) - right->interpreter(var);
}
};
Expression* analyse(string expStr) {
stack<Expression*> expStack;
Expression* left = nullptr;
Expression* right = nullptr;
for(int i=0; i<expStr.size(); i++)
{
switch(expStr[i])
{
case '+':
// 加法运算
left = expStack.top();
right = new VarExpression(expStr[++i]);
expStack.push(new AddExpression(left, right));
break;
case '-':
// 减法运算
left = expStack.top();
right = new VarExpression(expStr[++i]);
expStack.push(new SubExpression(left, right));
break;
default:
// 变量表达式
expStack.push(new VarExpression(expStr[i]));
}
}
Expression* expression = expStack.top();
return expression;
}
void release(Expression* expression){
//释放表达式树的节点内存...
}
int main(int argc, const char * argv[]) {
string expStr = "a+b-c+d-e";
map<char, int> var;
var.insert(make_pair('a',5));
var.insert(make_pair('b',2));
var.insert(make_pair('c',1));
var.insert(make_pair('d',6));
var.insert(make_pair('e',10));
Expression* expression= analyse(expStr);
int result=expression->interpreter(var);
cout<<result<<endl;
release(expression);
return 0;
}
要点总结：
<1> Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的结构不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。
<2>使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧来方便地“扩展”文法。
<3> Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interpreter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。
网友评论