話說這個世界還是混沌之時，盤古掄起一把大斧，開辟了天與地，從此，這個世界有天有地，萬事萬物在這個世界才慢慢發(fā)展起來。
話說軟件江湖還是混沌之時，無門無派，無招無式，GoF（Gang of Four，四個大師），窮理之熟，融會貫通，合著了《Design Patterns: Elements of Reusable Object-Oriented Software》（即《設(shè)計模式》）一書，從此，人人傳頌天下武功出少林，設(shè)計模式看GoF，這個江湖開始熱鬧起來了。(別人的話)
我們先看設(shè)計模式的原則：
一、設(shè)計模式的六大原則
總原則：開閉原則（Open Close Principle）
開閉原則就是說對擴(kuò)展開放，對修改關(guān)閉。在程序需要進(jìn)行拓展的時候，不能去修改原有的代碼，而是要擴(kuò)展原有代碼，實現(xiàn)一個熱插拔的效果。所以一句話概括就是：為了使程序的擴(kuò)展性好，易于維護(hù)和升級。想要達(dá)到這樣的效果，我們需要使用接口和抽象類等。
不要存在多于一個導(dǎo)致類變更的原因，也就是說每個類應(yīng)該實現(xiàn)單一的職責(zé)，如若不然，就應(yīng)該把類拆分。
2、里氏替換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向?qū)ο笤O(shè)計的基本原則之一。 里氏代換原則中說，任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。 LSP是繼承復(fù)用的基石，只有當(dāng)衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復(fù)用，而衍生類也能夠在基類的基礎(chǔ)上增加新的行為。里氏代換原則是對“開-閉”原則的補(bǔ)充。實現(xiàn)“開-閉”原則的關(guān)鍵步驟就是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體實現(xiàn)，所以里氏代換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范。—— From Baidu 百科
里氏替換原則中，子類對父類的方法盡量不要重寫和重載。因為父類代表了定義好的結(jié)構(gòu)，通過這個規(guī)范的接口與外界交互，子類不應(yīng)該隨便破壞它。
3、依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）
這個是開閉原則的基礎(chǔ)，具體內(nèi)容：面向接口編程，依賴于抽象而不依賴于具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。
4、接口隔離原則（Interface Segregation Principle）
這個原則的意思是：每個接口中不存在子類用不到卻必須實現(xiàn)的方法，如果不然，就要將接口拆分。使用多個隔離的接口，比使用單個接口（多個接口方法集合到一個的接口）要好。
5、迪米特法則（最少知道原則）（Demeter Principle）
就是說：一個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多么復(fù)雜，都應(yīng)該將邏輯封裝在方法的內(nèi)部，通過public方法提供給外部。這樣當(dāng)被依賴的類變化時，才能最小的影響該類。
最少知道原則的另一個表達(dá)方式是：只與直接的朋友通信。類之間只要有耦合關(guān)系，就叫朋友關(guān)系。耦合分為依賴、關(guān)聯(lián)、聚合、組合等。我們稱出現(xiàn)為成員變量、方法參數(shù)、方法返回值中的類為直接朋友。局部變量、臨時變量則不是直接的朋友。我們要求陌生的類不要作為局部變量出現(xiàn)在類中。
6、合成復(fù)用原則（Composite Reuse Principle）
原則是盡量首先使用合成/聚合的方式，而不是使用繼承。
二、再來看設(shè)計模式的分類：
將23種設(shè)計模式主要分為三大類：創(chuàng)建型、結(jié)構(gòu)型、行為型
1、創(chuàng)建型設(shè)計模式(共五個)
包括?
1.1、Singleton Pattern（單例模式）：保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。 單例模式是最簡單的設(shè)計模式之一。
1.2、Prototype?Pattern（原型模式）：用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這個原型來創(chuàng)建新的對象。
1.3、Factory Method?Pattern（工廠方法模式）：定義一個用于創(chuàng)建對象的接口，讓子類決定將哪一個類實例化。Factory Method使一個類的實例化延遲到其子類。
1.4、Abstract Factory?Pattern（抽象工廠模式）：提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。
1.5、Builder?Pattern（建造者模式）：將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
2、結(jié)構(gòu)型設(shè)計模式(共七種)：
包括
2.1、Adapter?Pattern（適配器模式）：將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
2.2、Bridge?Pattern（橋接模式）：將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化。
2.3、Composite?Pattern（組合模式）：將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。它使得客戶對單個對象和復(fù)合對象的使用具有一致性。
2.4、Decorator?Pattern（裝飾者模式）：動態(tài)地給一個對象添加一些額外的職責(zé)。就擴(kuò)展功能而言， 它比生成子類方式更為靈活。
2.5、Fa?ade?Pattern（外觀模式）：為子系統(tǒng)中的一組接口提供一個一致的界面， F a c a d e模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。
2.6、Flyweight?Pattern（享元模式）：運用共享技術(shù)有效地支持大量細(xì)粒度的對象。
2.7、Proxy?Pattern（代理模式）：為其他對象提供一個代理以控制對這個對象的訪問。
3、行為型設(shè)計模式(包含十一種)
3.1、Chain of Responsibility?Pattern（職責(zé)鏈模式）：為解除請求的發(fā)送者和接收者之間耦合，而使多個對象都有機(jī)會處理這個請求。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它。
3.2、Command?Pattern（命令模式）：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進(jìn)行參數(shù)化；對請求排隊或記錄請求日志，以及支持可取消的操作。
3.3、Interpreter?Pattern（解釋器模式）：給定一個語言, 定義它的文法的一種表示，并定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。
3.4、Iterator?Pattern（迭代器模式）：提供一種方法順序訪問一個聚合對象中各個元素, 而又不需暴露該對象的內(nèi)部表示。
3.5、Mediator?Pattern（中介者模式）：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
3.6、Memento?Pattern（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復(fù)到保存的狀態(tài)。
3.7、Observer?Pattern（觀察者模式）：定義對象間的一種一對多的依賴關(guān)系,以便當(dāng)一個對象的狀態(tài)發(fā)生改變時,所有依賴于它的對象都得到通知并自動刷新。
3.8、State?Pattern（狀態(tài)模式）：允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。對象看起來似乎修改了它所屬的類。
3.9、Strategy?Pattern（策略模式）：定義一系列的算法,把它們一個個封裝起來, 并且使它們可相互替換。本模式使得算法的變化可獨立于使用它的客戶。
3.10、Template Method?Pattern（模板方法模式）：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。
3.11、Visitor?Pattern（訪問者模式）：表示一個作用于某對象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
再細(xì)點分類：
