設計模式——行為模式（一）

前面我們討論了設計模式——建立型模式和設計模式——結構型模式，現在我們來討論設計模式中的行為模式。

行為模式是用在不同對象直接劃分職責和演算法的抽象，行為模式不僅涉及到類和對象，還涉及到類與對象之間如何進

行關聯。

可分為行為類模式和行為對象模式兩種：

1.行為類模式使用繼承機制在類間指派行為。

2.行為對象模式使用對象複合而不是繼承。一些行為對象模式描述了組對等的對象怎樣相互協作以完成其中任何一個i

額對象都無法單獨完成的任務。這裡一個重要的問題是對等對象如何相互瞭解對方。對等對象可以保持顯式的對對方

的引用，但是那會增加他們的耦合度。在極端情況下，每一個對象都要瞭解所以其他的對象。

行為型模式包括：

解譯器（Interperter）：

提供一個如何把語言元素包括在程式中的定義。

模板（Template）：

提供演算法的一個抽象定義。

職責鏈（Chain of Responsibility）：

把請求從鏈中的一個對象傳到下一個對象，直到請求被響應為止。通過這種方式去除對象之間的耦合。

命令（Command）：

用簡單的對象表示軟體命令的執行，支援登入和取消操作。

迭代（Iterator）：

提供一種順序訪問一個類中一系列資料的方式。

中介者（Mediator）：

定義了如何用一個對象簡化對象之間的通訊，使對象之間不必相互瞭解。

備忘錄（Memento）：

定義了如何儲存一個類的執行個體內容，以便以後恢複它。

觀察者（Observer）：

定義了一種把改動通知給多個對象的方式。

狀態（State）：

允許一個對象在其內部狀態改變時修改它的行為。

策略（Strategy）：

將演算法封裝到類中。

訪問者（Visitor）：

在不改變類的前提下，為一個類添加多種操作。

解譯器（interpreter）

定義：

給定一個語言，定義它的文法的一種表示，並定義一個解譯器，這個解譯器使用該表示來解釋語言中的句子。

 

結構圖：

 

解釋：一般的執行過程是這樣的，Client讀取Context中的資訊，根據某種原則將其劃分成多個部分，針對每一部分，

構造相應的解譯器，並將Context資訊傳入解譯器中進行處理。這裡的問題是Client必須要清楚Context細節和具體解釋

器中間的關聯。我們可以在Client和Interpreter之間構造一個“解譯器工廠”，用來根據Context產生相應的解譯器實

例，同樣，如果解譯器的執行過程和資料無關，我們可以為“解譯器工廠”上追加“單例”模式，構造一個解譯器

池。這些都是可以根據需求做的進一步的最佳化。

例子：音樂解譯器

 

模板方法（TemplateMethod）

 

定義：

定義一個操作中的演算法的骨架,而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個演算法的結構即可重定

義該演算法的某些特定步驟。

結構圖：

 

解釋：

可以看出，對於子類來說，它是不需要重寫TemplateMethod方法的，而只需要實現父類的抽象方法。對於用戶端來說，當它執行個體化某個子類後，可以直接調用TemplateMethod方法來完成某項業務。

例子：考題抄錯

 

職責鏈模式（Chain of Responsibility）

 

定義：

使多個對象都有機會處理請求，從而避免請求的寄件者和接收者之間的耦合關係。將這個對象連成一條鏈，並沿著這

條鏈傳遞該請求，直到有一個對象處理它為止。

結構圖:

解釋：

我們可以建立很多個Handler的實作類別，並通過設定SetSuccessor來將這些Handler“串”在一起。那麼如何觸發所有

的Handler呢？這裡和Decorator有點兒類似，我們可以通過調用SetSuccessor.HandlerRequest來實現。這樣使用者只

需要關心最開始的Handler，而不必關心後面都還有哪些其他的Handler。

例子：申請加薪

 

命令模式（Command）

 

定義：

將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支援可

撤銷的操作。

結構圖：

解釋：

，我們可以看到，當Client端需要執行某項業務時，它需要構造一個Invoker對象，它負責發出請求，會產生一個Command對象。同時我們看到有一個Receiver對象，它是用來實現具體業務的，我們在ConcreteCommand中，會引用這個對象，來完成具體業務。

例子：吃烤羊肉串