設計模式-行為型

一． 責任鏈模式

這種模式中，有發送者和接收者。通常，每個接收者都包含對另一個接收者的引用，形成一條鏈，如果一個接收者不能處理該請求，那么它會把相同的請求傳給下一個接收者，依次類推。

這種模式將請求的發送者和接收者解耦，但是不能保證請求一定被接收。

使用場景是有1. 多個對象可以處理同一個請求，具體哪個對象處理該請求由運行時刻自動確定。2. 在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。 3. 可動態指定一組對象處理請求。

這里有個特別形象的例子：
假設現在有個需求來了，首先是實習生拿到這個需求。
如果實習生能夠實現，直接實現。如果不行，他把這個需求交給初級工程師。
如果初級工程師能夠實現，直接實現。如果不行，交給中級工程師。
如果中級工程師能夠實現，直接實現。如果不行，交給高級工程師。
如果高級工程師能夠實現，直接實現。如果不行，交給 CTO。
如果 CTO能夠實現，直接實現。如果不行，直接跟產品說，需求不做。

這種模式和裝飾者模式有一定相似的地方。

二． 命令模式

根據菜鳥教程的描述，“在軟件系統中，行為請求者與行為實現者通常是一種緊耦合的關系，但某些場合，比如需要對行為進行記錄、撤銷或重做、事務等處理時，這種無法抵御變化的緊耦合的設計就不太合適”。

對于這個描述，我現在的理解不深。我理解的是，將一個請求用一個對象進行封裝，相當于在請求的發起者和請求之間加多一層，以便將請求者與請求進行解耦。

三． 解析器模式

這個看不太明白，感覺沒有應用的場景。

四． 迭代器模式

對這個理解的也不深，感覺用的也不多。

五． 中介者模式

用來降低多個對象和類之間的通信復雜性。這種模式提供了一個中介類，該類通常處理不同類之間的通信，并支持松耦合，使代碼易于維護。

具體的做法是將交聯型(網狀)的關系轉化為星型關系，1、系統中對象之間存在比較復雜的引用關系，導致它們之間的依賴關系結構混亂而且難以復用該對象。 2、想通過一個中間類來封裝多個類中的行為，而又不想生成太多的子類。缺點可能是中介者會龐大，變得復雜難以維護。具體的應用有mvc中的c的作用。

六． 備忘錄模式(應用比較少？)

主要解決：所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態，這樣可以在以后將對象恢復到原先保存的狀態。

何時使用：很多時候我們總是需要記錄一個對象的內部狀態，這樣做的目的就是為了允許用戶取消不確定或者錯誤的操作，能夠恢復到他原先的狀態，使得他有"后悔藥"可吃。

如何解決：通過一個備忘錄類專門存儲對象狀態。

關鍵代碼：客戶不與備忘錄類耦合，與備忘錄管理類耦合。

應用實例： 1、后悔藥。 2、打game時的存檔。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、數據庫的事務管理。

優點： 1、給用戶提供了一種可以恢復狀態的機制，可以使用戶能夠比較方便地回到某個歷史的狀態。 2、實現了信息的封裝，使得用戶不需要關心狀態的保存細節。

缺點：消耗資源。如果類的成員變量過多，勢必會占用比較大的資源，而且每一次保存都會消耗一定的內存。

七． 觀察者模式
當對象間存在一對多關系時，則使用觀察者模式（Observer Pattern）。比如，當一個對象被修改時，則會自動通知它的依賴對象。觀察者模式屬于行為型模式。應用是mvc中的事件機制。

八． 狀態模式
將一個狀態封裝為一個對象(狀態對象)，這個對象會依賴于持有該狀態的對象。狀態對象有一個或多個方法改變持有狀態的對象的行為。應用有: 狀態機，行為樹的動作節點等。

九． 空對象模式
to be continued……

十． 策略模式

意圖：定義一系列的算法,把它們一個個封裝起來, 并且使它們可相互替換。

主要解決：在有多種算法相似的情況下，使用 if...else 所帶來的復雜和難以維護。

何時使用：一個系統有許多許多類，而區分它們的只是他們直接的行為。

如何解決：將這些算法封裝成一個一個的類，任意地替換。

關鍵代碼：實現同一個接口。

應用實例： 1、諸葛亮的錦囊妙計，每一個錦囊就是一個策略。 2、飛機game里面的bullet。

優點： 1、算法可以自由切換。 2、避免使用多重條件判斷。 3、擴展性良好。

缺點： 1、策略類會增多。 2、所有策略類都需要對外暴露。

十一. 模板模式
to be continued……

十二. 訪問者模式
to be continued……

to be continued