設計模式-行爲型

一． 責任鏈模式

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

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

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

這種模式和裝飾者模式有必定類似的地方。

二． 命令模式

根據菜鳥教程的描述，「在軟件系統中，行爲請求者與行爲實現者一般是一種緊耦合的關係，但某些場合，好比須要對行爲進行記錄、撤銷或重作、事務等處理時，這種沒法抵禦變化的緊耦合的設計就不太合適」。

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

三． 解析器模式

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

四． 迭代器模式

對這個理解的也不深，感受用的也很少。

五． 中介者模式

用來下降多個對象和類之間的通訊複雜性。這種模式提供了一箇中介類，該類一般處理不一樣類之間的通訊，並支持鬆耦合，使代碼易於維護。

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

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

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

什麼時候使用：不少時候咱們老是須要記錄一個對象的內部狀態，這樣作的目的就是爲了容許用戶取消不肯定或者錯誤的操做，可以恢復到他原先的狀態，使得他有"後悔藥"可吃。

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

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

應用實例： 一、後悔藥。 二、打game時的存檔。 三、Windows 裏的 ctri + z。 四、IE 中的後退。 四、數據庫的事務管理。

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

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

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

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

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

十． 策略模式

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

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

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

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

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

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

優勢： 一、算法能夠自由切換。 二、避免使用多重條件判斷。 三、擴展性良好。

缺點： 一、策略類會增多。 二、全部策略類都須要對外暴露。

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

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

to be continued