一． 責任鍊模式
這種模式中，有發送者和接收者。通常，每個接收者都包含對另一個接收者的引用，形成一條鍊，如果一個接收者不能處理該請求，那麼它會把相同的請求傳給下一個接收者，依次類推。
這種模式将請求的發送者和接收者解耦，但是不能保證請求一定被接收。
使用場景是有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