【前言】
行爲型模式有觀察者模式、模板方法模式、命令模式、狀態模式、職責鏈模式、解釋器模式、中介者模式、訪問者模式、策略模式、備忘錄模式、迭代器模式。
在這裏先介紹觀察者模式、模板方法模式、命令模式、狀態模式、職責鏈模式。
【內容】
觀察者模式
定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。
優點
（1）觀察者和被觀察者是抽象耦合的。
（2）建立一套觸發機制。
缺點
（1）如果一個被觀察者對象有很多的直接和間接的觀察者的話，將所有的觀察者都通知到會花費很多時間。
（2）如果在觀察者和觀察目標之間有循環依賴的話，觀察目標會觸發它們之間進行循環調用，可能導致系統崩潰。
（3）觀察者模式沒有相應的機制讓觀察者知道所觀察的目標對象是怎麼發生變化的，而僅僅只是知道觀察目標發生了變化。
何時使用
一個對象（目標對象）的狀態發生改變，所有的依賴對象（觀察者對象）都將得到通知，進行廣播通知。
觀察者模式—UML圖
模板方法模式
定義一個操作的算法骨架，而將一些步驟延遲到子類中，模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
優點
（1）封裝不變部分，擴展可變部分。
（2）提取公共代碼，便於維護。
（3）行爲由父類控制，子類實現。
缺點
每一個不同的實現都需要一個子類來實現，導致類的個數增加，使得系統更加龐大。
何時使用
有一些通用的方法。
模板方法模式—UML圖
命令模式
將一個請求封裝爲一個對象，從而使你可用不同的請求對客戶進行參數化；可以對請求排隊或記錄請求日誌，以及支持可撤銷的操作。
優點
（1）降低了系統耦合度。
（2）新的命令可以很容易添加到系統中去。
缺點
使用命令模式可能會導致某些系統有過多的具體命令類。
何時使用
在某些場合，比如要對行爲進行"記錄、撤銷/重做、事務"等處理，這種無法抵禦變化的緊耦合是不合適的。在這種情況下，如何將"行爲請求者"與"行爲實現者"解耦？將一組行爲抽象爲對象，可以實現二者之間的鬆耦合。
命令模式—UML圖
狀態模式
允許一個對象在其內部狀態改變時改變它的行爲，讓對象看起來似乎修改了它的類。
優點
（1）封裝了轉換規則。
（2）枚舉可能的狀態，在枚舉狀態之前需要確定狀態種類。
（3）將所有與某個狀態有關的行爲放到一個類中，並且可以方便地增加新的狀態，只需要改變對象狀態即可改變對象的行爲。
（4）允許狀態轉換邏輯與狀態對象合成一體，而不是某一個巨大的條件語句塊。
（5）可以讓多個環境對象共享一個狀態對象，從而減少系統中對象的個數。
缺點
（1）狀態模式的使用必然會增加系統類和對象的個數。
（2）狀態模式的結構與實現都較爲複雜，如果使用不當將導致程序結構和代碼的混亂。
（3）狀態模式對“開閉原則”的支持不是很大，對於可以切換狀態的狀態模式，增加新的狀態類需要修改那些複雜狀態轉換的源代碼，否則無法切換到新增狀態，而且修改某個狀態類的行爲也需要修改對象類的源代碼。
何時使用
代碼中包含大量與對象狀態有關的條件語句。
狀態模式—UML圖
職責鏈模式
使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止。
優點
（1）降低耦合度。它將請求的發送者和接收者解耦。
（2）簡化了對象。使得對象不需要知道鏈的結構。
（3）增強給對象指派職責的靈活性。通過改變鏈內的成員或者調動它們的次序，允許動態地新增或者刪除責任。
（4）增加新的請求處理類很方便。
缺點
（1）不能保證請求一定被接收。
（2）系統性能將受到一定影響，而且在進行代碼調試時不太方便，可能會造成循環調用。
（3）可能不容易觀察運行時的特徵，有礙於除錯。
何時使用
在處理消息的時候以過濾很多道。
職責鏈模式—UML圖
