設計模式——行爲型模式

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.中介者模式

用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互。

我們都知道，面向對象設計鼓勵將行爲分佈到各個對象中。但是，這種分佈可能會導致對象間有許多連接。在最壞的情況下，每一個對象都知道其他所有對象，就造成了複雜的關聯關係。雖然將一個系統分割成許多對象通常可以增強可複用性，但是對象間相互連接的激增又會降低其可複用性。大量的相互連接使得一個對象似乎不太可能在沒有其他對象的支持下工作，這樣使得系統表現爲一個不可分割的整體。而且，對系統的行爲進行任何較大的改動都十分困難，因爲行爲被分佈在許多對象中。結果是，你可能不得不定義很多子類以定製系統的行爲。