對<code>《Head First 設計模式》</code>中的常用設計模式的整理，其實很多模式我們在開發中都有用到，但是在此之前沒有一種理論基礎支撐自己，有了這些知識後，更有利于做好程式的設計工作，以及遇到一些設計問題時知道如何取舍。
通過組合不同的算法，為系統提供運作時動态地改變行為的功能，使系統具有更大的彈性。
定義了算法族，把它們分别封裝起來，讓它們之間可以互相替換，此模式讓算法的變化獨立于使用算法的客戶之上。
通過使用觀察者模式，使多個對象之間松耦合，但是它們依然可以互動，但是不用清楚彼此的細節。
定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀态時，它的所有依賴者都會收到通知并自動更新。
裝飾者可以在被裝飾者的行為前面或後面加上自己的行為，甚至将被裝飾者的行為整個取代掉，進而達到某種特定的目的。
動态地将責任附加到對象上。若要拓展功能，裝飾者提供了比繼承更有彈性的替代方案。
通過讓子類決定該建立的對象是什麼，來達到将對象建立的過程封裝的目的。
定義了一個建立對象的接口，但由子類決定要執行個體化的類是哪一個。工廠方法讓類把執行個體化推遲到子類。
抽象工廠允許客戶使用抽象的接口來建立一組相關的産品，而不需要知道（或關心）實際産出的具體産品是什麼，這樣一來，客戶就從具體的産品中被解耦。
提供一個接口，用于建立相關或依賴對象的家族，而不需要明确指定具體類。
坦白說，工廠方法與抽象工廠的相似度很高，從類圖上看很難将它們理清楚，但是從定義上來看的話會發現它們的差別主要是在設計層次上，以我們大家熟悉的電子産品為例，如果有兩個産品：手機、電腦，用工廠方法表示蘋果和三星的類圖：
從品牌的角度上來看，兩家廠商生産不同的手機和電腦，這樣的工廠方法很清晰；但是如果我們把生産條件做的更細緻一點的話，比如蘋果面向中國的産品和面向美國的産品是不同的，面向中國大陸銷售的産品是閹割過的，而美國的是全功能的，用抽象工廠表示就像這樣：
抽象工廠的每一個子類都像是一個工廠方法，就像抽象工廠的定義所說的那樣：用于建立相關或依賴對象的家族。
建立一個獨一無二的對象。
確定一個類隻有一個執行個體，并提供一個全局通路點。
通過統一的接口操作不同的對象，使系統能夠輕易的實作多種目的。
将“請求”封裝成對象，以便使用不同的請求、隊列或者日志來參數化其他對象。指令模式也支援可撤銷的操作。
擴充卡可以将改變的接口封裝起來，客戶就不必為了應對不同的接口而每次跟着修改。
将一個類的接口，轉換成客戶期望的另一個接口。擴充卡讓原本接口不相容的類可以合作無間。
将一個或數個類的複雜的一切都隐藏在背後，隻顯露出一個幹淨美好的外觀。
提供了一個統一的接口，用來通路子系統中的一群接口。外觀定義了一個高層接口，讓子系統更容易使用。
将算法定義成一組步驟，其中的任何步驟都可以是抽象的，由子類負責實作。這可以確定算法的結構保持不變，同時由子類提供部分實作。
在一個方法中定義一個算法的骨架，而将一些步驟延遲到子類中。模闆方法使得子類可以在不改變算法結構的情況下，重新定義算法中的某些步驟。
讓我們能遊走于集合中的每一個元素，而又不暴露其内部的表示。
提供一種方法順序通路一個集合對象中的各個元素，而又不暴露其内部的表示。
能夠建立一個樹形結構，在同一個結構中處理嵌套菜單和菜單項組。
允許你将對象組合成樹形結構來表現“整體/部分”層次結構。組合能讓客戶以一緻的方式處理個别對象以及對象組合。
将狀态封裝成獨立的類，并将動作委托到代表目前狀态的對象，使行為随着内部狀态而改變。
允許對象在内部狀态改變時改變它的行為，對象看起來好像修改了它的類。
讓代理對象控制對某個對象的通路，被代理的對象可以是遠端的對象、建立開銷大的對象或需要安全控制的對象。
為另一個對象提供一個替身或占位符以控制對這個對象的通路。
代理是個複雜的模式，變種頗多，不同的變種甚至就有不同的類圖。
封裝變化
多用組合，少用繼承
針對接口程式設計，不針對實作程式設計
為互動對象之間的松耦合設計而努力
類應該對拓展開放，對修改關閉
依賴抽象，不要依賴具體類
隻和朋友交談
别找我，我會找你
類應該隻有一個改變的理由
…