设计模式原则
- 单一职责原则（SRP）
- 就一个类而言，应该仅有一个引起它变化的原因
- 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力
- 开放-封闭原则
- 软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。
- 两个特征，对于扩展开放，对于更改封闭
- 依赖倒转原则
- 高层模块不应该依赖低层模块，两个都应该依赖抽象
- 抽象不应该依赖细节，细节应该依赖抽象
- 里氏代换原则（LSP）
- 子类型必须能够替换掉它们的父类型，即在软件里面，把父类都替换成它的子类，程序的行为没有变化
- 迪米特法则（LoD）（最少知识原则）
- 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中一个类需要调用另一个类的某一个额方法的话，可以通过第三者转发这个调用
- 前提：在类的结构设计上，每一个类应当尽量降低成员的访问权限
UML类图
- 类图分三层：类名（抽象类，斜体表示）、类的特性（字段和属性）、类的操作（方法或行为）
- 符号：+表示public、-表示private、#表示protected
- 接口图
- 顶端<>、第一行接口名称、第二行接口方法
- 棒棒糖表示法，圆圈旁为接口名称、接口方法在实现类中出现
- 继承关系用空心三角形+实线表示
- 实现接口用空心三角形+虚线表示
- 关联关系用实线箭头表示，以类对象形式
- 聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；聚合关系用空心的菱形+实线箭头表示
- 合成是一种强的“拥有”关系
- 体现了严格的部分和整体的关系，部分和整体的生命周期一样
- 合成关系用实心的菱形+实线箭头表示
- 合成关系的连线两端的数字为基数，表明这一端的类可以有几个实例
- 依赖关系用虚线箭头表示
简单工厂模式、工厂模式、抽象工厂模式
- 工厂模式
- 定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类
- 抽象工厂模式
- 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类
- 优缺点
- 易于交换产品系列，由于具体工厂类，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置
- 它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操作实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中
策略模式
- 它定义了算法家族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户
class Context
{
private:
Strategy *strategy;
public:
Context(Strategy *strategy):strategy(strategy){}
~Context(){}
void ContextInterface()
{
strategy->AlgorithmInterface();
}
};
装饰模式
- 动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活
- 优点：把类中的装饰功能从类中搬移去除，简化原有的类；有效地把类的核心职责和装饰功能区分开了，去除了相关类中重复的装饰逻辑
- 结构
- Component（抽象类）：定义一个对象接口，可以给这些对象动态的添加职责
- ConcreteComponent（继承自Component）：定义一个具体的对象，也可以给这个对象添加一些职责
- Decorator（装饰抽象类，继承自Component）：从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的
- ConcreteDecoratorA、ConcreteDecoratorB：具体的装饰对象，起到给Component添加职责的功能（可以是数据成员，也可以是成员函数形式）
class Decorator:public Component
{
protected:
Component *m_component;
public:
Decorator();
virtual ~Decorator();
void set_component(Component *component)
{
m_component = component;
}
void operation()
{
if(m_component != NULL)
{
m_component->operation();
}
}
};
int main()
{
ConcreteComponent c = new ConcreteComponent();
ConcreteDecoratorA *d1 = new ConcreteDecoratorA();
ConcreteDecoratorB *d2 = new ConcreteDecoratorB();
d1->set_component(c);
d2->set_component(d1);
d2.operation();
return 0;
}
代理模式
- 为其他对象提供一种代理以控制对这个对象的访问
- 适用场景
- 远程代理：为一个对象在不同的地址空间提供局部代表，这样可以隐藏一个对象存在于不同地址空间的事实。例：引用WebService
- 虚拟代理：根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。例：浏览器中用代理模式优化下载
- 安全代理：用来控制真实对象访问时的权限。一般用于对象应该有不同的访问权限的时候
- 智能指引：当调用真实的对象时，代理处理另外一些事
class Proxy:Interface
{
private:
Subject *subject;
public:
Proxy()
{
subject = new Subject();
}
~Proxy(){}
void request()
{
subject->request();
}
};
原型模式
- 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
class Resume
{
protected:
string m_name;
public:
Resume(string name);
virtual ~Resume();
virtual Resume *clone() = 0;
};
class ResumeA:public Resume
{
public:
ResumeA(string name);
~ResumeA();
ResumeA(const ResumeA &a):Resume(a.m_name){}
ResumeA *clone(){return new ResumeA(*this);}
};
模板方法模式
- 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
- 当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。我们通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠
class AbstractClass
{
protected:
virtual void primitive_operation1() = 0;
virtual void primitive_operation2() = 0;
public:
AbstractClass();
virtual ~AbstractClass();
void template_method()
{
primitive_operation1();
primitive_operation2();
}
};
class ConcreteClass:public AbstractClass
{
protected:
void primitive_operation1();
void primitive_operation2();
public:
ConcreteClass();
~ConcreteClass();
};
外观模式
- 为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
- 何时使用
- 在设计初期阶段，应该要有意识的将不同的两个层分离，层与层之间建立外观Facade
- 在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖
- 在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。
建造者模式（生成器模式）
- 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
- 建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式
class Product
{
private:
list<string> parts;
public:
Product();
~Product();
void add(string part)
{
parts.push_back(part);
}
void show()
{
list<string>::iterator iter;
for (iter = parts.begin(); iter != parts.end(); iter++)
{
cout << *iter << endl;
}
}
};
class Builder
{
public:
Builder();
virtual ~Builder();
virtual void build_part1() = 0;
virtual void build_part2() = 0;
virtual Product *get_product() = 0;
};
class ConcreteBuilder:public Builder
{
private:
Product *product;
public:
ConcreteBuilder()
{
product = new Product();
}
~ConcreteBuilder();
void build_part1();
void build_part2();
Product *get_product()
{
return product;
}
};
class Director
{
public:
Director();
~Director();
void build(Builder *builder)
{
builder->build_part1();
builder->build_part2();
}
};
观察者模式（发布-订阅模式）
- 定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己
- 结构
- Subject类，可翻译为主题或抽象通知者，一般用一个抽象类或者一个接口实现。它把所有对观察者对象的引用保存在一个聚集里，每一个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象
- Observer类，抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。这个接口叫做更新接口。抽象观察者一般用一个抽象类或者一个接口实现。更新接口通常包含一个Update()方法，这个方法叫做更新方法。
- ConcreteSubject类，叫做具体主题或具体通知者，将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常用一个具体子类实现。
- ConcreteObserver类，具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。具体观察者角色可以保存一个指向具体主题对象的引用。具体观察者角色通常用一个具体子类实现
- 使用时机
- 当一个对象的改变需要同时改变其他对象，且不知道具体有多少对象有待改变时
- 一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用
- 委托
- 一种引用方法的类型，一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法的使用可以像其他任何方法一样，具有参数和返回值。委托可以看作是对函数的抽象，是函数的“类”，委托的实例将代表一个具体的函数
- 前提：委托对象所搭载的所有犯法必须具有相同的原型和形式，也就是拥有相同的参数列表和返回值类型
class Subject
{
private:
list<Observer *> observers;
public:
void attach(Observer *observer)
{
observers.push_back(observer);
}
void detach(Observer *observer)
{
observers.remove(observer);
}
void notify()
{
for(...)
{
->update();
}
}
};
class ConcreteSubject:public Subject
{
private:
string state;
public:
string get_state() const
{
return state;
}
void set_state(string state)
{
this->state = state;
}
};
class Observer
{
public:
virtual void update() = 0;
};
class ConcreteObserver
{
private:
string name;
string state;
ConcreteSubject *subject;
public:
ConcreteObserver(ConcreteSubject *subject, string name)
{
this->subject = subject;
this->name = name;
}
void update()
{
state = subject->get_state();
}
string get_state() const
{
return state;
}
void set_state(string state)
{
this->state = state;
}
};
int main()
{
ConcreteSubject *s = new ConcreteSubject();
s->attach(new ConcreteObserver(s, "X"));
s->attach(new ConcreteObserver(s, "Y"));
s->set_state("ABC");
s->notify();
}
状态模式
- 当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类
- 优点：将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。可以消除庞大的条件分支语句
- 状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖
- 使用时机
- 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时
- 若业务需求某项业务有多个状态，通常都是一些枚举常量，状态的变化都是依靠大量的多分支判断语句来实现，此时应该考虑将每一种业务状态定义为一个State的子类，这样这些对象就可以不依赖于其他对象而独立变化了，某一天客户需要更改需求，增加或减少业务状态或改变状态流程，就不是难事
class State
{
public:
State(){}
virtual ~State(){}
virtual void handle(Context *context) = 0;
};
class Context
{
private:
State *state;
public:
Context(State *state)
{
this->state = state;
}
~Context(){}
void set_state(State *state)
{
this->state = state;
}
void request()
{
state->handle(this);
}
};
class ConcreteStateA:public State
{
public:
void handle(Context *context)
{
if()
{
}
else
{
context->set_state(new ConcreteStateB();
context->handle(this);
}
}
};
class ConcreteStateB:public State
{
public:
void handel(Context *context)
{
if()
{
}
else
{
context->set_state(new ConcreteStateA();
context->handle(this);
}
}
};
适配器模式（对象适配器）
- 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
- 系统的数据和行为都正确，但接口不符时，我们应该考虑使用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些显存的类，但是接口又与复用环境要求不一致的情况
class Target
{
public:
virtual void request() = 0;
};
class Adaptee
{
public:
void specific_request()
{
}
};
class Adapter:public Target
{
private:
Adaptee *adaptee;
Adapter()
{
adaptee = new Adaptee();
}
void request()
{
adaptee->specific_request();
}
};
备忘录模式（Memento）
- 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态
- Memento模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的实行知识众多属性中的一小部分时，Originator可以根据保存的Memento信息还原到前一状态
class Memento
{
int hd;
int atk;
int def;
public:
Memento(int hd, int atk, int def);
~Memento();
int get_hd();
int get_atk();
int get_def();
};
class Game
{
int hd;
int atk;
int def;
public:
Game(int hd, int atk, int def);
~Game();
void display();
void fight();
Memento *save_state()
{
return new Memento(hd, atk, def);
}
void recover_state(Memento *menento)
{
hd = memento->get_hd();
atk = memento->get_atk();
def = memento->get_def();
}
};
class Management
{
Memento *memento;
public:
Management();
~Management();
void set_memento(Memento *memento)
{
this->memento = memento;
}
Memento *get_memento()
{
return memento;
}
};
组合模式（Composite）
- 将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性
- 透明方式：在Component中声明所有用来管理子对象的方法，其中包括Add、Remove等，这样实现Component接口的所有子类都具备了Add和Remove。这样做的好处就是叶节点和枝节点对于外界没有区别，它们具备完全一致的行为接口。但问题也很明显，因为Leaf类本身不具备Add()、Remove()方法的功能，所以实现它时没有意义的
- 安全方式：在Component接口中不去声明Add和Remove方法，那么子类的Leaf也就不需要去实现它，而是在Composite声明所有用来管理子类对象的方法，这样做不会出现透明方法中的缺点，不过由于不够透明，所以树叶和树枝类将不具有相同的接口，客户端的调用需要做相应的判断，带来了不便
class Component
{
protected:
string name;
public:
Component(string name);
~Component();
virtual void add(Component *c) = 0;
virtual void remove(Component *c) = 0;
};
class Composite:public Component
{
list<Component *> children;
public:
Composite();
~Composite();
void add(Component *c)
{
children.push_back(c);
}
void remove(Component *c)
{
children.remove(c);
}
};
int main()
{
Composite *root = new Composite("root");
root->add(new Leaf("Leaf A"));
root->add(new Leaf("Leaf B"));
Composite *comp = new Composite("Composite X");
comp->add(new Leaf("Leaf XA"));
comp->add(new Leaf("Leaf XB"));
root->add(comp);
return 0;
}
迭代器模式（Iterator）
- 提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示
单例模式（Singleton）
- 保证一个类仅有一个实例，并提供一个访问它的全局访问点
- 单例模式因为Singleton类封装它的唯一实例，这样它可以严格地控制客户怎么样访问它以及何时访问它。简单来说就是对唯一实例的受控访问
class Singleton
{
Singleton();
static void delete_instance();
static Singleton *instance;
public:
~Singleton()
{
delete_instance();
}
static Singleton *get_instance();
};
Singleton *Singleton::instance = NULL;
void Singleton::delete_instance()
{
instance = NULL;
}
Singleton *Singleton::get_instance()
{
if(NULL == instance)
{
instance = new Singleton();
}
return instance;
}
int main()
{
Singleton *ins = Singleton::get_instance();
delete ins;
ins = NULL;
ins = Singleton::get_instance();
delete ins;
ins = NULL;
return 0;
}
桥接模式
- 对象的继承关系是在编译时就定义好了，所以无法在运行时改变从父类继承的实现。子类的实现与它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。
- 合成/聚合复用原则（CARP）
- 尽量使用合成/聚合，尽量不要使用类继承
- 聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分
- 合成则是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样
- 优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物
- 桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变化
class Brand
{
protected:
Software *software;
public:
Brand();
virtual ~Brand();
virtual void run() = 0;
};
class BrandA:public Brand
{
public:
BrandA(Software *software);
~BrandA();
void run()
{
software->run();
}
};
命令模式
- 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作
- 优点
- 能较容易地设计一个命令队列
- 在需要的情况下，可以较容易地将命令计入日志
- 允许接收请求的一方是否要否决请求
- 可以容易地实现对请求的撤销和重做
- 由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易
- 命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开
- 敏捷开发原则：不要为代码添加基于猜测的，实际不需要的功能，如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。
class Command
{
protected:
Receiver *receiver;
public：
Command();
virtual ~Command();
virtual void execute() = 0;
};
class ConcreteCommand:public Command
{
public:
ConcreteCommand(Receiver *receiver)
{
this->receiver = receiver;
}
void execute()
{
receiver->action();
}
};
class Invoker
{
private:
Command *command;
public:
Invoker();
~Invoker();
void set_command(Command *command)
{
this->command = command;
}
void execute_command()
{
command->execute();
}
};
class Receiver
{
public:
Receiver();
~Receiver();
void action();
};
职责链模式
- 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止
- 当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHandler对象负责处理它。
- 接收者和发送至都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需要保持它所有的候选接收者的引用，大大降低了耦合度
- 由于是在客户端来定义链的结构，所以可以随时增加或修改处理一个请求的结构，增强了给对象指派职责的灵活性
- 一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理。
class Handler
{
protected:
Hander *successor;
public:
void set_successor(Handler *successor)
{
this->successor = successor;
}
virtual void handle_request(int request) = 0;
};
class ConcreteHandler1:public Handler
{
public:
void handle_request(int request)
{
if(request >= 0 && request < 10)
{
}
else if(successor != NULL)
{
successor->handle_request(request);
}
}
};
int main()
{
Handler *h1 = new ConcreteHandler1();
Handler *h2 = new ConcreteHandler2();
Handler *h3 = new ConcreteHandler3();
h1->set_successor(h2);
h2->set_successor(h3);
int array[] = {2, 15, 22, 5};
for(int i = 0; i < 4; i++)
{
h1->handle_request(array[i]);
}
return 0;
}
中介者模式（调停者模式 Mediator）
- 尽管将一个系统分割成许多对象通常可以增加其可复用性，但是对象间相互连接的激增又会降低其可复用性。因为大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分困难
- 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
- 中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合
- 缺点
- 中介者模式很容易在系统中应用，也很容易在系统中误用。当系统出现了“多对多”交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理
- 由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂
- 优点
- Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator
- 由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统
class Mediator
{
public:
virtual void send(Colleague *colleague, string message) = 0;
};
class Colleague
{
protected:
Mediator *mediator;
public:
Colleague();
virtual ~Colleague();
};
class CocnreteColleague1:public Colleague
{
public:
ConcreteColleague1(Mediator *mediator);
void send(string message)
{
mediator->send(this, message);
}
void notify(string message)
{
}
};
class ConcreteColleague2:public Colleague
{
public:
ConcreteColleague2(Mediator *mediator);
void send(string message)
{
mediator->send(this, message);
}
void notify(string message)
{
}
};
class ConcreteMediator:public Mediator
{
ConcreteColleague1 *colleague1;
ConcreteColleague2 *colleague2;
public:
void set_colleague1(ConcreteColleague *value)
{
colleague1 = value;
}
void set_colleague2(ConcreteColleague *value)
{
colleague2 = value;
}
void send(Colleague *colleague, string message)
{
if(colleague == colleague1)
{
colleague2->notify(message);
}
else
{
colleague2->notify(message);
}
}
};
int main()
{
Mediator *m = new ConcreteMediator();
ConcreteColleague1 *c1 = new ConcreteColleague1(m);
ConcreteColleague2 *c2 = new ConcreteColleague2(m);
m->set_colleague1(c1);
m->set_colleague2(c2);
c1->send("吃过饭了吗？");
c2->send("没有呢，你打算请客？");
return 0;
}
享元模式（Flyweight）
- 运用共享技术有效地支持大量细粒度的对象
- 在享元对象内部并且不会随环境改变而改变的共享部分，可以称是享元对象的内部状态，而随环境改变而改变的、不可以共享的状态就是外部状态了
- 享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的，有时就能够大幅度减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数量
- 如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部化，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式
解释器模式（interpreter）
- 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
- 如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子，这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题
- 可以容易地改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为定义抽象语法树中各个节点的类的实现答题类似，这些类都易于直接编写
- 解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其他技术如语法分析程序或编译器生成器来处理
class AbstractExpression
{
public:
virtual void Interpret(Context *context) = 0;
};
class TerminalExpression:public AbstractExpression
{
public:
void interpret(Context *context)
{
}
};
class NonterminalExpression:public AbstractExpression
{
public:
void interpret(Context *context)
{
}
};
class Context
{
private:
string input;
string output;
};
访问者模式（Visitor）
- 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作
- 访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化
- 访问者模式的目的是要把处理从数据结构分离出来
- 如果系统有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式就是比较合适的，因为访问者模式使得算法操作的增加变得容易
- 访问者模式的优点就是增加新的操作很容易，因为增加新的操作就意味着增加一个恶心的访问者。访问者模式将有关的行为集中到一个访问者对象中
class Visitor
{
public:
virtual void visit_concrete_elementA(ConcreteElementA *concreteElementA) = 0;
virtual void visit_concrete_elementB(ConcreteElementB *concreteElementB) = 0;
};
class ConcreteVisitor1:public Visitor
{
public:
void visit_concrete_elementA(ConcreteElementA *concreteElementA)
{
}
visit_concrete_elementB(ConcreteElementB *concreteElementB)
{
}
};
class ConcreteVisitor2:public Visitor
{
};
class Element
{
public:
virtual void accept(Visitor *visitor) = 0;
};
class ConcreteElementA:public Element
{
public:
void accept(Visitor *visitor)
{
visitor->visit_concrete_elementA(this);
}
void operationA()
{
}
};
class ConcreteElementB:public Element
{
public:
void accept(Visitor *visitor)
{
visitor->visit_concrete_elementB(this);
}
void operationB()
{
}
};
class ObjectStructure
{
private:
list<Element *> elements;
public:
void attach(Element *element)
{
elements.push_back(element);
}
void detach(Element *element)
{
elements.remove(element);
}
void accept(Visitor *visitor)
{
for(...)
{
->accept(visitor);
}
}
};
int main()
{
ObjectStructure *o = new ObjectStructure();
o->attach(new ConcreteElementA());
o->attach(new ConcreteElementB());
ConcreteVisitor1 *v1 = new ConcreteVisitor1();
ConcreteVisitor2 *v2 = new ConcreteVisitor2();
o->accept(v1);
o->accept(v2);
return 0;
}
设计模式分类
- 创建型模式
- 抽象工厂、建造者、工厂、原型、单例
- 创建型模式隐藏了这些类的实例是如何被创建和放在一起，整个系统关于这些对象所知道的是由抽象类所定义的接口。这样，创建型模式在创建了什么、谁创建它、它是怎么被创建的，以及何时创建这些方面提供了很大的灵活性
- 创建型模式抽象了实例化的过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。创建型模式都会将关于该系统使用哪些具体的类的信息封装起来。允许客户用结构和功能差别很大的“产品”对象配置一个系统。配置可以是静态的，即在编译时指定，也可以是动态的，就是运行时再指定
- 原型模式：建立相应数目的原型并克隆它们通常比每次用合适的状态手工实例化该类更方便一些
- 松耦合：内聚性描述的是一个例程内部组成部分之间相互联系的紧密程度。而耦合性描述的是一个例程与其他例程之间联系的紧密程度。软件开发的目标应该是创建这样的例程：内部完整，也就是高内聚，而与其他例程之间的联系则是小巧、直接、可见、灵活的
- 结构型模式
- 行为型模式
- 观察者、模板、命令、状态、职责链
- 解释器、中介者、访问者、策略、备忘录、迭代器
13万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
