二十一、單例模式（Singleton）
定義：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
1、通常我們可以讓一個全局變量使得一個對象被訪問，但它不能防止你實例化多個對象。一個最好的辦法就是，讓類自身負責保存它的唯一實例。這個類可以保證沒有其他的實例可以被創建，並且它可以提供一個訪問該實例的方法。
2、注意在多線程時，如果不加鎖，會有可能造成創建多個實例的，需要lock，lock是確保當一個線程位於代碼的臨界區時，另一個線程不進入臨界區。如果其他線程試圖進入鎖定的代碼，則它將一直等待，直到該對象被釋放。
二十二、橋接模式（Bridge）
定義：將抽象部分與它的實現部分分離，使他們都可以獨立的變化。
個人感悟：在思考具體業務時，應優先考慮組合、聚合等鬆耦合的關係，因爲大部分業務特別是較爲複雜的業務肯定不可能用繼承等強耦合來表達，可以通過組合聚合來搭建業務需求，在細節部分用繼承的強耦合實現。記住不能盲目使用繼承，繼承是一種強耦合關係，父類變化子類也要必須變化，喪失了靈活性，繼承是一種is-a的關係。我感覺橋接模式不僅僅是代碼設計模式，其實就是組織代碼的思維邏輯，當然設計模式就是設計的模式，就是組織代碼的模式，就是如何根據具體業務的需求來組織代碼，從而達到優雅的目的。
1、設計原則：合成、聚合複用原則，即優先使用對象合成、聚合，而不是類繼承
2、聚合表示一種弱的擁有關係，體現的是A對象可以包含B對象，但B對象不是A對象的一部分；合成則是一種強的擁有關係，體現了嚴格的部分和整體的關係，部分和整體的生命週期是一樣的。
3、優先使用對象的合成、聚合將有助於你保持每個類被封裝，並被集中在單個任務上。這樣類和類繼承層次會保持較小規模，並且不太可能增長爲不可控的龐然大物。
4、什麼叫抽象與它的實現分離？並不是說讓抽象類與其派生類分離，因爲這沒有任何意義。實現指的是抽象類和它派生類用來實現自己的對象。
5、實現系統可能有多角度分類，每一種分類都可能有變化，那麼把這種多角度分離出來讓他們獨立變化，減少他們之間的耦合
6、在發現我們需要多角度去分離實現對象，而只用繼承會造成大量的類增加，不能滿足開發-封閉原則時，就應該考慮用橋接模式。
7、只要真正深入的理解了設計原則，很多設計模式其實就是原則的應用而已，或許在不知不覺中就使用設計模式了
二十三、命令模式（Command）
定義：將一個請求封裝爲一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可撤銷的操作。
優點：1、較容易地設計一個命令隊列 2、在需要的情況下，可以較容易地將命令記入日誌 3、允許接收請求的一方決定是否否決請求 4、可以容易地實現對請求的撤銷和重做 5、由於加進新的具體命令類不影響其他的類，因此增加新的具體命令類很容易。最關鍵的優點是命令模式把請求一個操作的對象與知道怎麼執行一個操作的對象分割開。
1、敏捷開發的原則告訴我們，不要爲代碼添加基於猜測的、實際不需要的功能，如果不清楚一個系統是否需要命令模式，一般就不要急着去實現它。
二十四、責任鏈模式（Chain of Responsibility）
定義：使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係，將這個對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理爲止。
特點：當客戶提交一個請求時，請求是沿鏈傳遞直至有一個ConcreteHandler對象負責處理它，這樣做的好處是請求者不用管哪個對象來處理，這使得接受者和發送者都沒有對方的明確信息，且鏈中的對象自己也並不知道鏈的結構。
感悟：其實一個簡單的請求會直接在一個類中處理，如果請求的的處理業務很複雜，涉及多種可能，例如本書的例子，客戶請求假期，處理請求涉及到上級、高層、boss，如果在一個類中if else來處理的話，結構不清晰，用責任鏈來把具體業務進行分割
二十五、中介者模式（Mediator）
定義：中介者模式用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互
二十六、享元模式（Flyweight）
定義：享元模式，運用共享技術有效地支持大量細粒度的對象。