設(shè)計模式-行為型

一． 責(zé)任鏈模式

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

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

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

這里有個特別形象的例子：
假設(shè)現(xiàn)在有個需求來了，首先是實習(xí)生拿到這個需求。
如果實習(xí)生能夠?qū)崿F(xiàn)，直接實現(xiàn)。如果不行，他把這個需求交給初級工程師。
如果初級工程師能夠?qū)崿F(xiàn)，直接實現(xiàn)。如果不行，交給中級工程師。
如果中級工程師能夠?qū)崿F(xiàn)，直接實現(xiàn)。如果不行，交給高級工程師。
如果高級工程師能夠?qū)崿F(xiàn)，直接實現(xiàn)。如果不行，交給 CTO。
如果 CTO能夠?qū)崿F(xiàn)，直接實現(xiàn)。如果不行，直接跟產(chǎn)品說，需求不做。

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

二． 命令模式

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

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

三． 解析器模式

這個看不太明白，感覺沒有應(yīng)用的場景。

四． 迭代器模式

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

五． 中介者模式

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

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

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

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

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

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

關(guān)鍵代碼：客戶不與備忘錄類耦合，與備忘錄管理類耦合。

應(yīng)用實例： 1、后悔藥。 2、打game時的存檔。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、數(shù)據(jù)庫的事務(wù)管理。

優(yōu)點： 1、給用戶提供了一種可以恢復(fù)狀態(tài)的機制，可以使用戶能夠比較方便地回到某個歷史的狀態(tài)。 2、實現(xiàn)了信息的封裝，使得用戶不需要關(guān)心狀態(tài)的保存細節(jié)。

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

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

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

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

十． 策略模式

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

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

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

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

關(guān)鍵代碼：實現(xiàn)同一個接口。

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

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

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

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

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

to be continued