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

標籤：設計模式   行為型模式   觀察者模式   模板方法模式   狀態模式   

設計模式的第三大類型——行為模式，下面是對觀察者模式、模板方法模式、命令模式、狀態模式、職責鏈模式這五個的讀後總結，歡迎交流！

 

     觀察者模式（Observer）：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。[大話設計模式]

       特點：類似於物件導向的多態，只是物件導向多態講的是同一對象在不同時間和不同條件下表現不同狀態，而觀察者模式的多態則講求的是某一操作（或命令）引起的不同對象在同一時間作出反應，這個反應可相同、可不同，可展示不同的功能、顯示不同的現象。

       使用：一個對象的改變需要同時改變其他對象的時候。

       協助：用委託來解決“觀察者模式的多態”的方法不同名，無法統一行動的難題。

 

     模板方法模式（Template Method）：定義一個操作的演算法骨架，而將一些步驟延遲到子類中，模板方法使得子類可以不改變一個演算法的結構及可定義該演算法的某些特定步驟。[大話設計模式]

       特點：實現大量代碼的複用，而不是複製。這樣在客觀上保證了模板下的執行個體的一致性，又在後期的維護中提供了便利。與物件導向的繼承的意義如出一轍。

       使用：當我們要完成在某一細節層次一致的一個過程或一系列步驟，但其個別步驟在更詳細的層次上的實現可能不同時，我們通常考慮用模板方法模式。

 

     命令模式（Command）：將一個請求封裝為一個對象，從而使你可用不同的請求對用戶端進行參數化；可以對請求排隊或記錄請求日誌，以及支援可撤銷的操作。[大話設計模式]

       特點：可以對請求排隊並按順序處理命令，還支援撤銷操作。

       提示：敏捷開發原則告訴我們，不要為代碼添加基於猜測的實際不需要的功能。

       使用：如果不清楚一個系統是否需要命令模式，一般就不要著急去實習它，事實上，在需要的時候通過重構實現這個模式並不困難，只有在真正需要如撤銷/恢複操作等功能時，把原來的代碼重構為命令模式才有意義。[大話設計模式]

 

     狀態模式（State）：當一個對象的內在狀態改變時允許改變其行為，這個對象看起來像是改變了其類。

       特點：狀態模式通過把各種狀態轉移邏輯分布到State的子類之間，來減少相互間的依賴。

       提示：在使用過程中，多用到判斷語句，這就需要，這些判斷語句將狀態的變化分成階段，需要注意的是，在劃分範圍時要考慮齊全，不能出現遺漏或重疊，避免發生錯誤。如果因實際造成劃分過散，最好添加使用錯誤引導語句規避。

       使用：當一個對象的行為取決於它的狀態，並且它必須在運行時刻根據狀態改變它的行為時，就可以考慮使用狀態模式了。

 

     職責鏈模式（Chain of Responsibility）：使多個對象有機會處理請求，從而避免請求的寄件者和接收者之間的耦合關係。將這些對象連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個對象處理它為止。[大話設計模式]

       特點：一個請求，順著職權由低向高請求，直到有權處理並處理掉為止。

       提示：請求沿著鏈傳遞，直到有對象處理它為止。要問了，到最後也沒有處理怎麼辦呢？這要規避，在設計時就需要考慮周到，最後最好使用錯誤引導語句。

使用：對於一個請求，如果需要審定職權後，才能處理時。