橋接模式(Bridge)
使用橋接模式不只改變你的實現，也改變你的抽象。橋接模式通過將實現和抽象放在兩個不同的類層次中而使它們可以獨立改變。
橋接的優點：
-將實現予以解耦，讓它和界面之間不再永久綁定。
-抽象和實現可以獨立擴展，不會影響到對方。
-對于“具體的抽象類”所做的改變，不會影響到客戶。
橋接的用途和缺點：
-適合使用在需要跨越多個平臺的圖形和窗口系統上。
-當需要用不同的方法改變接口和實現時，你會發現橋接模式很好用。
-橋接模式的缺點是增加了復雜度。
示例：控制器與界面各自的抽象
生成器模式(Builder)
-使用生成器模式封裝一個產品的構造過程，并允許按步驟構造。
生成器的優點：
-將一個復雜對象的創建過程封裝起來。
-允許對象通過多個步驟來創建，并且可以改變過程（這和只有一個步驟的工程模式不同）。
-向客戶隱藏產品內部的實現。
-產品的實現可以被替換，因為客戶只看到一個抽象的接口。
生成器的用途和缺點：
-經常被用來創建組合結構
-與工廠模式相比，采用生成器模式創建對象的客戶，需要具備更多的領域知識。
示例：度假計劃
責任鏈模式(Chain of responsibility)
當你想要讓一個以上的對象有機會能夠處理某個請求的時候，就使用責任鏈模式。
責任鏈模式的優點：
-將請求的發送者和接受者解耦
-可以簡化你的對象，因為它不需要知道鏈的結構
-通過改變鏈內的成員或調動它們的次序，允許你動態地新增或者刪除責任
責任鏈的用途與缺點：
-經常被使用在窗口系統中，處理鼠標和鍵盤之類的事件
-并不保證請求一定會被執行；如果沒有任何對象處理它的話，它可能會落到鏈尾之外（這可以是優點也可以是缺點）
-可能不容易觀察運行時的特征，有礙于除錯
示例：不同郵件（垃圾郵件，Fans郵件，客服郵件，業務郵件等）的處理
享元模式(Flyweight)
如想讓某個類的一個實例能用來提供許多“虛擬實例”，就是用享元模式
享元模式的優點：
-減少運行時對象實例的個數，節省內存
-將許多“虛擬對象”的狀態集中管理
享元模式的用途與缺點：
-當一個類有許多的實例，而這些實例能被同一方法控制的時候，我們就可以使用享元模式
-缺點：一旦你實現了它，那么單個的邏輯實例將無法擁有獨立而不同的處理
享元模式
示例：景觀設計中的點綴樹的顯示（只一個樹實例，共享位置年輪信息）
解釋器模式(Intepreter)
使用解釋器模式為語言創建解釋器
解釋器的優點：
-將每一個語法規則表示成一個類，方便于實現語言
-因為語法由許多類表示，所以你可以輕易地改變或擴展此語言
-通過在類結構中加入新的方法，可以在解釋的同時增加新的行為，例如打印格式的美化或者進行復雜的程序驗證
解釋器的用途與缺點：
-當你需要實現一個簡單的語言時，使用解釋器
-當你有一個簡單的語法，而且簡單比效率更重要時，使用解釋器
-可以處理腳本語言和編程語言
-當語言規則的數碼太大時，這個模式可能會變得相當繁雜，在這種情況下，使用解釋器/編譯器的產生器可能更合適
示例：Duck pond控制鴨子的語言解釋器
中介者模式(Mediator)
使用中介者模式來集中相關對象之間復雜的溝通和控制方式。每個對象都會在自己的狀態改變時，告訴中介者，每個對象都會對中介者所發出的請求作出反應。中介者內包含了整個系統的控制邏輯。當某個對象需要一個新的規則時，或者是一個新的對象被加入系統內，其所有需要用到的邏輯也都被加入中介者內。
中介者模式的優點：
-通過將對象彼此解耦，可以增加對象的復用性
-通過將控制邏輯集中，可以簡化系統維護
-可以讓對象之間所傳遞的消息變得簡單而且大幅減少
中介者模式的用途和缺點：
-中介者模式常常被用來協調相關的GUI組件
-中介者模式的缺點是：如果設計不當，中介者對象本身會變得過于復雜
示例：生活自動機（鬧鈴，煮咖啡，日歷，噴頭）
備忘錄模式(Memento)
當你需要讓對象返回之前的狀態時(例如:undo)，就使用備忘錄模式。備忘錄模式有兩個目標：儲存系統關鍵對象的重要狀態；維護關鍵對象的封裝。請不要忘記單一責任原則，不要把保持狀態的工作和關鍵對象混在一起，這樣比較好。這個專門掌握狀態的對象就稱為備忘錄。
備忘錄模式的優點：
-被儲存的狀態放在外面，不要和關鍵對象混在一起，這可以幫助維護內聚
-保持關節對象的數據封裝
-提供了容易實現的恢復能力
備忘錄模式的用途和缺點：
-備忘錄用于儲存狀態
-使用備忘錄的缺點：儲存和恢復狀態的過程可能相當耗時
-在Java系統中，其實可以考慮使用序列化(Serialization)機制儲存系統的狀態
示例：游戲中的存儲進度功能
原型模式(Prototype)
當創建給定類的實例的過程很昂貴或很復雜時，就使用原型模式。原型模式允許你通過使用復制現有的實例來創建新的實例（在Java中，這通常意味著使用clone()方法或者反序列化）。這個模式的重點在于，客戶的代碼在不知道要實例化何種特定類的情況下，可以制造出新的實例。
原型模式的優點：
-向客戶隱藏制造新實例的復雜性
-提供客戶能夠產生未知類型對象的選項
-在某些環境下，復制對象比創建新對象更有效
原型模式的用途和缺點：
-在一個復雜的類層次中，當系統必須從其中的許多類型創建新對象時，可以考慮原型
-缺點：對象的復制有時相當復雜
示例：在游戲中創建各式各樣的怪獸
訪問者模式(Visitor)
當你想要為一個對象的組合增加新的能力，且封裝并不重要時，就使用訪問者模式。
客戶要求訪問者從組合結構中取得信息，新方法可以被加入到訪問者中，而不會影響組合；訪問者需要能夠調用組合類的getState()，而這也正是你能夠加入新方法以讓客戶使用的地方；所有的這些組合類必須做的事情就是加入一個getState()方法，而不必擔心暴露他們自己。
訪問者模式的優點：
-允許你對組合結構加入新的操作，而不需改變結構本身
-想要加入新的操作，相對容易
-訪問者所進行的操作，其代碼是集中在一起的
訪問者模式的用途和缺點：
-當采用訪問者模式的時候，就會打破組合類的封裝
-因為游走的功能牽涉其中，所以對組合結構的改變就更加困難
示例：對鄉村餐廳的菜單添加營養成分，能量顯示