一.設計模式的分類

設計模式總體來說分為三大類：

1. 創(chuàng)建型模式
   共五種：工廠方法模式厨相、抽象工廠模式领曼、單例模式鸥鹉、建造者模式、原型模式庶骄。
2. 結構性模式
   共七種：適配器模式毁渗、裝飾器模式、代理模式单刁、外觀模式祝蝠、橋接模式、組合模式幻碱、享元模式。
3. 行為型模式
   共十一種：策略模式细溅、模板方法模式褥傍、觀察者模式、迭代子模式喇聊、責任鏈模式恍风、命令模式、備忘錄模式誓篱、狀態(tài)模式朋贬、訪問者模式、中介者模式窜骄、解釋器模式锦募。

具體如下：

創(chuàng)建型：
一、Singleton邻遏，單例模式：保證一個類只有一個實例糠亩，并提供一個訪問它的全局訪問點
二、Abstract Factory准验，抽象工廠：提供一個創(chuàng)建一系列相關或相互依賴對象的接口赎线， 而無須指定它們的具體類。
三糊饱、Factory Method垂寥，工廠方法：定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪 一個類另锋，F(xiàn)actory Method 使一個類的實例化延遲到了子類滞项。
四、Builder夭坪，建造模式：將一個復雜對象的構建與他的表示相分離蓖扑，使得同樣的構建 過程可以創(chuàng)建不同的表示。
五台舱、Prototype律杠，原型模式：用原型實例指定創(chuàng)建對象的種類潭流，并且通過拷貝這些原型 來創(chuàng)建新的對象。

行為型：
六柜去、Iterator灰嫉，迭代器模式：提供一個方法順序訪問一個聚合對象的各個元素，而又不 需要暴露該對象的內部表示嗓奢。
七讼撒、Observer，觀察者模式：定義對象間一對多的依賴關系股耽，當一個對象的狀態(tài)發(fā)生 改變時根盒，所有依賴于它的對象都得到通知自動更新。
八物蝙、Template Method炎滞，模板方法：定義一個操作中的算法的骨架，而將一些步驟延遲 到子類中诬乞，TemplateMethod 使得子類可以不改變一個算法的結構即可以重定義該算法得某 些特定步驟册赛。
九、Command震嫉，命令模式：將一個請求封裝為一個對象森瘪，從而使你可以用不同的請求 對客戶進行參數(shù)化，對請求排隊和記錄請求日志票堵，以及支持可撤銷的操作扼睬。
十、State悴势，狀態(tài)模式：允許對象在其內部狀態(tài)改變時改變他的行為痰驱。對象看起來似乎 改變了他的類。
十一瞳浦、Strategy担映，策略模式：定義一系列的算法，把他們一個個封裝起來叫潦，并使他們可 以互相替換蝇完，本模式使得算法可以獨立于使用它們的客戶。
十二矗蕊、China of Responsibility短蜕，職責鏈模式：使多個對象都有機會處理請求，從而避免 請求的送發(fā)者和接收者之間的耦合關系
十三傻咖、Mediator朋魔，中介者模式：用一個中介對象封裝一些列的對象交互。
十四卿操、Visitor警检，訪問者模式：表示一個作用于某對象結構中的各元素的操作孙援，它使你 可以在不改變各元素類的前提下定義作用于這個元素的新操作。
十五扇雕、Interpreter拓售，解釋器模式：給定一個語言，定義他的文法的一個表示镶奉，并定義一 個解釋器础淤，這個解釋器使用該表示來解釋語言中的句子。
十六哨苛、Memento鸽凶，備忘錄模式：在不破壞對象的前提下，捕獲一個對象的內部狀態(tài)建峭， 并在該對象之外保存這個狀態(tài)玻侥。

結構型有：
十七、Composite迹缀，組合模式：將對象組合成樹形結構以表示部分整體的關系，Composite 使得用戶對單個對象和組合對象的使用具有一致性蜜徽。
十八祝懂、Facade，外觀模式：為子系統(tǒng)中的一組接口提供一致的界面拘鞋， Facade提供了一 高層接口砚蓬，這個接口使得子系統(tǒng)更容易使用。
十九盆色、Proxy灰蛙，代理模式：為其他對象提供一種代理以控制對這個對象的訪問
二十、Adapter,適配器模式：將一類的接口轉換成客戶希望的另外一個接口隔躲，Adapter 模式使得原本由于接口不兼容而不能一起工作那些類可以一起工作摩梧。
二十一、Decrator宣旱，裝飾模式：動態(tài)地給一個對象增加一些額外的職責仅父，就增加的功 能來說，Decorator 模式相比生成子類更加靈活浑吟。
二十二笙纤、Bridge，橋模式：將抽象部分與它的實現(xiàn)部分相分離组力，使他們可以獨立的變 化省容。
二十三、Flyweight燎字，享元模式

• 其實還有兩類：并發(fā)型模式和線程池模式腥椒。

以上設計模式了解清楚后可以在這里看一下它們之間的關系：

二.設計模式的六大原則：

• 總原則：開閉原則（Open Close Principle）
  開閉原則就是說對擴展開放阿宅，對修改關閉。在程序需要進行拓展的時候寞酿，不能去修改原有的代碼家夺，而是
  要擴展原有代碼，實現(xiàn)一個熱插拔的效果伐弹。所以一句話概括就是：為了使程序的擴展性好拉馋，易于維護和
  升級。想要達到這樣的效果惨好，我們需要使用接口和抽象類等煌茴，后面的具體設計中我們會提到這點。

• 1. 單一職責原則
     不要存在多于一個導致類變更的原因日川，也就是說每個類應該實現(xiàn)單一的職責蔓腐，如若不然，就應該把類拆分龄句。
• 2. 里氏替換原則
     里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一回论。 里氏代換原則中說， 任何基類可以出現(xiàn)的地方分歇，子類一定可以出現(xiàn)傀蓉。 LSP 是繼承復用的基石，只有當衍生類可以替換掉基類职抡，軟件單位的功能不受到影響時葬燎，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為缚甩。里氏代換原則是對“開-閉”原則的補充谱净。實現(xiàn)“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現(xiàn)擅威，所以里氏代換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范壕探。—— From Baidu
     里氏替換原則中郊丛，子類對父類的方法盡量不要重寫和重載浩蓉。因為父類代表了定義好的結構，通過這個規(guī)范的接口與外界交互宾袜，子類不應該隨便破壞它捻艳。
• 3. 依賴反轉/依賴于抽象 原則（Dependence Inversion Principle）
     這個是開閉原則的基礎，具體內容：面向接口編程庆猫，依賴于抽象而不依賴于具體认轨。寫代碼時用到具體類時，不與具體類交互月培，而與具體類的上層接口交互嘁字。
• 4. 接口隔離原則（Interface Segregation Principle）
     每個接口中不存在子類用不到卻必須實現(xiàn)的方法恩急，如果不然，就要將接口拆分纪蜒。使用多個隔離的接口衷恭，比使用單個接口（多個接口方法集合到一個的接口）要好。
• 5. 迪米特法則（最少知道原則）（Demeter Principle）
     一個類對自己依賴的類知道的越少越好纯续。 也就是說無論被依賴的類多么復雜随珠，都應該將邏輯封裝在方法的內部，通過 public 方法提供給外部猬错。這樣當被依賴的類變化時窗看，才能最小的影響該類。 最少知道原則的另一個表達方式是：只與直接的朋友通信倦炒。類之間只要有耦合關系显沈，就叫朋友關系。耦合分為依賴逢唤、關聯(lián)拉讯、聚合、組合等鳖藕。我們稱出現(xiàn)為成員變量魔慷、方法參數(shù)、方法返回值中的類為直接朋友吊奢。局部變量盖彭、臨時變量則不是直接的朋友纹烹。我們要求陌生的類不要作為局部變量出現(xiàn)在類中页滚。
• 6. 合成復用原則（Composite Reuse Principle）
     原則是盡量首先使用合成/聚合的方式，而不是使用繼承铺呵。