標籤：
在GoF的《Design Patterns: Elements of Reusable Object-Oriented Software》中給出了三類（建立型[對類的執行個體化過程的抽象化]、結構型[描述如何將類或對象結合在一起形成更大的結構]、行為型[對在不同的對象之間劃分責任和演算法的抽象化]）共23種設計模式，包括：Abstract Factory（抽象原廠模式），Builder（建造者模式），Factory Method（Factory 方法模式），Prototype（原始模型模式），Singleton（單例模式）；Facade（門面模式），Adapter（適配器模式），Bridge（橋樑模式），Composite（合成模式），Decorator（裝飾模式），Flyweight（享元模式），Proxy（代理模式）；Command（命令模式），Interpreter（解譯器模式），Visitor（訪問者模式），Iterator（迭代子模式），Mediator（調停者模式），Memento（備忘錄模式），Observer（觀察者模式），State（狀態模式），Strategy（策略模式），Template Method（模板方法模式）， Chain Of Responsibility（責任鏈模式）。
所謂設計模式，就是一套被反覆使用的代碼設計經驗的總結（情境中一個問題經過證實的一個解決方案）。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。設計模式使人們可以更加簡單方便的複用成功的設計和體繫結構。將已證實的技術表述成設計模式也會使新系統開發人員更加容易理解其設計思路。
【補充】設計模式並不是像某些地方吹噓的那樣是遙不可及的編程理念，說白了設計模式就是對物件導向的編程原則的實踐，物件導向的編程原則包括：
- 單一職責原則：一個類只做它該做的事情。（單一職責原則想表達的就是“高內聚”，寫代碼最終極的原則只有六個字“高內聚、低耦合”，就如同葵花寶典或辟邪劍譜的中心思想就八個字“欲練此功必先自宮”，所謂的高內聚就是一個代碼模組只完成一項功能，在物件導向中，如果只讓一個類完成它該做的事，而不涉及與它無關的領域就是踐行了高內聚的原則，這個類就只有單一職責。我們都知道一句話叫“因為專註，所以專業”，一個對象如果承擔太多的職責，那麼註定它什麼都做不好。這個世界上任何好的東西都有兩個特徵，一個是功能單一，好的相機絕對不是電視購物裡面賣的那種一個機器有一百多種功能的，它基本上只能照相；另一個是模組化，好的單車是組裝車，從減震叉、刹車到變速器，所有的組件都是可以拆卸和重新組裝的，好的乒乓球拍也不是成品拍，一定是底板和膠皮可以拆分和自行組裝的，一個好的軟體系統，它裡面的每個功能模組也應該是可以輕易的拿到其他系統中使用的，這樣才能實現軟體複用的目標。）
- 開閉原則：軟體實體應當對擴充開放，對修改關閉。（在理想的狀態下，當我們需要為一個軟體系統增加新功能時，只需要從原來的系統派生出一些新類就可以，不需要修改原來的任何一行代碼。要做到開閉有兩個要點：①抽象是關鍵，一個系統中如果沒有抽象類別或介面系統就沒有擴充點；②封裝可變性，將系統中的各種可變因素封裝到一個繼承結構中，如果多個可變因素混雜在一起，系統將變得複雜而換亂，如果不清楚如何封裝可變性，可以參考《設計模式精解》一書中對橋樑模式的講解的章節。）
- 依賴倒轉原則：面向介面編程。（該原則說得直白和具體一些就是聲明方法的參數類型、方法的傳回型別、變數的參考型別時，儘可能使用抽象類別型而不用具體類型，因為抽象類別型可以被它的任何一個子類型所替代，請參考下面的裡氏替換原則。）
- 裡氏替換原則：任何時候都可以用子類型替換掉父類型。（關於裡氏替換原則的描述，Barbara Liskov女士的描述比這個要複雜得多，但簡單的說就是能用父類型的地方就一定能使用子類型。裡氏替換原則可以檢查繼承關係是否合理，如果一個繼承關係違背了裡氏替換原則，那麼這個繼承關係一定是錯誤的，需要對代碼進行重構。例如讓貓繼承狗，或者狗繼承貓，又或者讓正方形繼承長方形都是錯誤的繼承關係，因為你很容易找到違反裡氏替換原則的情境。需要注意的是：子類一定是增加父類的能力而不是減少父類的能力，因為子類比父類的能力更多，把能力多的對象當成能力少的對象來用當然沒有任何問題。）
- 介面隔離原則：介面要小而專，絕不能大而全。（臃腫的介面是對介面的汙染，既然介面表示能力，那麼一個介面只應該描述一種能力，介面也應該是高度內聚的。例如，琴棋書畫就應該分別設計為四個介面，而不應設計成一個介面中的四個方法，因為如果設計成一個介面中的四個方法，那麼這個介面很難用，畢竟琴棋書畫四樣都精通的人還是少數，而如果設計成四個介面，會幾項就實現幾個介面，這樣的話每個介面被複用的可能性是很高的。Java中的介面代表能力、代表約定、代表角色，能否正確的使用介面一定是編程水平高低的重要標識。）
- 合成彙總複用原則：優先使用彙總或合成關係複用代碼。（通過繼承來複用代碼是物件導向程式設計中被濫用得最多的東西，因為所有的教科書都無一例外的對繼承進行了鼓吹從而誤導了初學者，類與類之間簡單的說有三種關係，IS-A關係、HAS-A關係、USE-A關係，分別代表繼承、關聯和依賴。其中，關聯關係根據其關聯的強度又可以進一步劃分為關聯、彙總和合成，但說白了都是HAS-A關係，合成彙總複用原則想表達的是優先考慮HAS-A關係而不是IS-A關係複用代碼，原因嘛可以自己從百度上找到一萬個理由，需要說明的是，即使在Java的API中也有不少濫用繼承的例子，例如Properties類繼承了Hashtable類，Stack類繼承了Vector類，這些繼承明顯就是錯誤的，更好的做法是在Properties類中放置一個Hashtable類型的成員並且將其鍵和值都設定為字串來儲存資料，而Stack類的設計也應該是在Stack類中放一個Vector對象來儲存資料。記住：任何時候都不要繼承工具類，工具是可以擁有並可以使用的（HAS/USE），而不是拿來繼承的。）
- 迪米特法則：迪米特法則又叫最少知識原則，一個對象應當對其他對象有儘可能少的瞭解。（迪米特法則簡單的說就是如何做到“低耦合”，門面模式和調停者模式就是對迪米特法則的踐行。對於門面模式可以舉一個簡單的例子，你去一家公司洽談業務，你不需要瞭解這個公司內部是如何運作的，你甚至可以對這個公司一無所知，去的時候只需要找到公司入口處的前台美女，告訴她們你要做什麼，她們會找到合適的人跟你接洽，前台的美女就是公司這個系統的門面。再複雜的系統都可以為使用者提供一個簡單的門面，Java Web開發中作為前端控制器的Servlet或Filter不就是一個門面嗎，瀏覽器對伺服器的運作方式一無所知，但是通過前端控制器就能夠根據你的請求得到相應的服務。調停者模式也可以舉一個簡單的例子來說明，例如一台電腦，CPU、記憶體、硬碟、顯卡、音效卡各種裝置需要相互配合才能很好的工作，但是如果這些東西都直接連接到一起，電腦的布線將異常複雜，在這種情況下，主板作為一個調停者的身份出現，它將各個裝置串連在一起而不需要每個裝置之間直接交換資料，這樣就減小了系統的耦合度和複雜度。迪米特法則用通俗的話來將就是不要和陌生人打交道，如果真的需要，找一個自己的朋友，讓他替你和陌生人打交道。）
你所熟悉或聽說過的設計模式以及你對設計模式的看法
