设计模式——行为型模式

1.策略模式※

策略模式定义了算法家族，分别封装起来，让它们之间可以互相转换，此模式让算法的变化，不会影响到使用算法的用户。

策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。这本身并没有解除客户端需要选择判断的压力，所以策略模式配合常常可以简单工厂使用。

2.观察者模式※

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化，关注它的对象就会得到通知；这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者。

class Observer

{

public:

Observer() {};

~Observer() {};



virtual void update(int) = 0;

};



class ConCreteObserverA : public Observer

{

public:

void update(int state)

{

cout << "A get state : " << state << endl;

}



};



class ConCreteObserverB : public Observer

{

public:

void update(int state)

{

cout << "B get state : " << state << endl;

}



};



class Subject

{

public:

Subject() {};

~Subject() {};



virtual void connect(Observer* ob) = 0;

virtual void disconnect(Observer* ob) = 0;



private:

};



class ConcreteSubject : public Subject

{

public:

void connect(Observer* ob)

{

_myObvs.push_back(ob);

}



void disconnect(Observer* ob)

{

_myObvs.remove(ob);

}



void SetState(int state)

{

_state = state;

notify();

}



private:



void notify()

{

for (auto it = _myObvs.begin(); it != _myObvs.end(); ++it)

{

(*it)->update(_state);

}

}



list<Observer*> _myObvs;

int _state;

};



int main()

{

Observer* oba = new ConCreteObserverA();

Observer* obb = new ConCreteObserverB();

ConcreteSubject *sub = new ConcreteSubject();

sub->connect(oba);

sub->connect(obb);

sub->SetState(1);

return 0;

}

3.解释器模式

给定一门语言，定义他的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

4.模板方法模式

定义一个操作的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

实现方案：将算法/逻辑框架放在抽象基类中，并定义好实现接口，在子类中实现细节接口。

注：策略模式，解决的是相同的问题，只是其方案是将各个接口封装为类，通过委托/组合方式解决问题。

5.迭代子模式

提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标(Cursor)。

6.责任链模式

使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象链成一条链，并沿着这条链传递该请求/命令，直到有对象处理它为止。

注：这里的请求、命令正是可以和命令模式进行结合的地方

7.命令模式

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。在OOP中，一切都是对象，将请求封装成对象，符合OOP的设计思想，当将客户的单个请求封装成对象以后，我们就可以对这个请求存储更多的信息，使请求拥有更多的能力；命令模式同样能够把请求发送者和接收者解耦，使得命令发送者不用去关心请求将以何种方式被处理。

8.备忘录模式

备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态[DP]。举个简单的例子，我们玩游戏时都会保存进度，所保存的进度以文件的形式存在。这样下次就可以继续玩，而不用从头开始。这里的进度其实就是游戏的内部状态，而这里的文件相当于是在游戏之外保存状态。这样，下次就可以从文件中读入保存的进度，从而恢复到原来的状态。这就是备忘录模式。

Memento类定义了内部的状态，而Caretake类是一个保存进度的管理者，GameRole类是游戏角色类。

9.状态模式

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

10.访问者模式

访问者模式（Visitor Pattern）表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。

11.中介者模式

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

我们都知道，面向对象设计鼓励将行为分布到各个对象中。但是，这种分布可能会导致对象间有许多连接。在最坏的情况下，每一个对象都知道其他所有对象，就造成了复杂的关联关系。虽然将一个系统分割成许多对象通常可以增强可复用性，但是对象间相互连接的激增又会降低其可复用性。大量的相互连接使得一个对象似乎不太可能在没有其他对象的支持下工作，这样使得系统表现为一个不可分割的整体。而且，对系统的行为进行任何较大的改动都十分困难，因为行为被分布在许多对象中。结果是，你可能不得不定义很多子类以定制系统的行为。