設計模式： 一個設計模式描述了一個被證實可行的方案。這些方案非常普遍，是具有完整定義的最常用的模式。一般模式有4個基本要素：模式名稱（pattern name）、問題（problem）、解決方案（solution）、效果（consequences）。
常見23種模式概述：
1） 抽象工廠模式（Abstract Factory）：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
2） 適配器模式（Adapter）：將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由於接口不兼容而不能一起工作的類可以一起工作。
3） 橋樑模式（Bridge）：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
4） 建造模式（Builder）：將一個複雜對象的構建與它的表示分離，使同樣的構建過程可以創建不同的表示。
5） 責任鏈模式（Chain of Responsibility）：爲解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它。
6） 命令模式（Command）：將一個請求封裝爲一個對象，從而可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可取消的操作。
7） 合成模式（Composite）：將對象組合成樹形結構以表示“部分－整體”的層次結構。它使得客戶對單個對象和複合對象的使用具有一致性。
8） 裝飾模式（Decorator）：動態地給一個對象添加一些額外的職責。就擴展功能而言，它能生成子類的方式更爲靈活。
9） 門面模式（Facade）：爲子系統中的一組接口提供一個一致的界面，門面模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
10） 工廠方法（Factory Method）：定義一個用於創建對象的接口，讓子類決定將哪一個類實例化。Factory Method 使一個類的實例化延遲到其子類。
11） 享元模式（Flyweight）：運用共享技術以有效地支持大量細粒度的對象。
12） 解釋器模式（Interpreter）：給定一個語言，定義它的語法的一種表示，並定義一個解釋器，該解釋器使用該表示解釋語言中的句子。
13） 迭代子模式（Iterator）：提供一種方法順序訪問一個聚合對象中的各個元素，而又不需暴露該對象的內部表示。
14） 調停者模式（Mediator）：用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式的內部表示。
15） 備忘錄模式（Memento）：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到保存的狀態。
16） 觀察者模式（Observer）：定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並自動刷新。
17） 原始模型模式（Prototype）：用原型實例指定創建對象的種類，並且通過拷貝這個原型創建新的對象。
18） 代理模式（Proxy）：爲其他對象提供一個代理以控制對這個對象的訪問。
19） 單例模式（Singleton）：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
20） 狀態模式（State）：允許一個對象在其內部狀態改變時改變它的行爲。對象看起來似乎修改了它所屬的類。
21） 策略模式（Strategy）：定義一系列的算法，把它們一個個封裝起來，並且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。
22） 模板模式（Template Method）：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
23） 訪問者模式（Visitor）：表示一個作用於某對象結構中的各元素的操作。該模式可以實現在不改變各元素的類的前提下定義作用於這些元素的新操作。
也許有人會問：“爲什麼要學習設計模式呢？”原因有很多，一些非常明顯，而另一些則不那麼明顯。
學習模式最常見的理由是因爲我們可以借其：
● 複用解決方案——通過複用已經公認的設計，我能夠在解決問題時取得先發優勢，而且避免重蹈前人覆轍。我可以從學習他人的經驗中獲益，用不着爲那些總是會重複出現的問題再次設計解決方案了。
● 確立通用術語——開發中的交流和協作都需要共同的詞彙基礎和對問題的共識。設計模式在項目的分析和設計階段提供了共同的基準點。
模式還爲我們提供了觀察問題、設計過程和麪向對象的更高層次的視角，這將使我們從“過早處理細節”的桎梏中解放出來。
等你讀完本書的時候，我希望你將同意這是學習設計模式的最重要的原因之一。它將改變你的思維定式，使你成爲更加高效的分析人員。
爲了說明這一優點，我想引述一段兩個木匠之間關於“如何爲櫥櫃製作抽屜”的談話。
想像一下，有兩個木匠在討論怎樣爲櫥櫃製作抽屜。
木匠甲：你認爲我們應該怎樣製作這些抽屜？
木匠乙：這個嘛，我想榫子應該這樣做：在木料上直着鋸下去，然後向迴轉45°再鋸，接着再直着鋸，然後換一個方向45°往回鋸，接着再直着鋸下去，然後……
現在，你要做的就是搞清楚他們說的是什麼意思！
這段描述是不是讓人不知所云？木匠乙到底給出了什麼建議？細節往往就是如此！讓我們試着將他的敘述畫出來。
這聽上去像不像似曾相識的代碼評審？在評審中有一位程序員這樣描述自己的代碼：
然後，我在這裏用一個WHILE 循環來……接着是一系列IF語句執行……這裏我用一條SWITCH語句處理……
你獲得的是對代碼細節的描述，而對“程序到底要做什麼”、“爲什麼這麼做”，你卻毫無頭緒!
當然，正經的職業木匠可不會這樣說話。真實的情形應該是這樣：
木匠甲：我們應該用鳩尾榫還是斜榫？
看到這裏的本質區別沒有？木匠們現在討論的是一個問題的解決方案上的本質差異，他們的討論層次更高、也更抽象了，從而避免了陷入具體解決方案的細節泥沼中。
當木匠談到“斜榫”時，他的腦子裏已經對這個解決方案浮現出如下特徵：
● 它是一個更簡單的解決方案——斜榫更容易製作。只需將製作榫的木料鋸出45°斜面，然後用釘子或者木膠接合起來即可。
● 它更輕型——斜榫比鳩尾榫強度低。在重壓下，將無法保持榫接。
● 它不太引人注目——斜榫的一個鋸面，與鳩尾榫的多個鋸面相比，更不顯眼。
當木匠談到“鳩尾榫”時，他的腦子裏浮現出另一些特徵。這些特徵對外行來說可能並不明顯，但任何一位木匠都會明白如故：
● 它是一個更復雜的解決方案——製作鳩尾榫涉及的問題更多。因此，它的成本也更高。
● 它不容易受溫度和溼度影響——當溫度和溼度變化時，木材會膨脹或收縮，但是，鳩尾榫仍然能夠保持堅固。
● 它與緊固系統無關——事實上，鳩尾榫甚至不需要依賴膠水。
● 它看上去更賞心悅目——如果製作精良，會很美觀。
也就是說，鳩尾榫是一個堅固、可靠、美觀的榫，但製作複雜（所以成本也比較高）。
所以，當木匠甲這樣問的時候：
我們應該用鳩尾榫還是斜榫？
他真正要問的問題是：
我們是應該用一個製作昂貴但美觀耐用的榫，還是應該只用一個製作快速而且不美觀的榫，能堅持到檢查結束就行？
我們應該說，木匠們的討論其實是在兩個層次上進行的：他們話語表面上的層次，和談話真正的內容，層次更高，外行聽不出來，而其中含義卻非常豐富。這種更高的層次就是“木匠模式”的層次，它反映了木匠眼中的真正的設計問題。
在第1種情形中，木匠乙討論的是榫的實現細節，反而使真正的問題模糊不清。在第2種情形中，木匠甲要根據榫的成本和接合性質來決定使用哪種榫。
誰更有效率呢？你更願意與誰一起工作？