一、設計模式的分類

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

創(chuàng)建型模式，共五種：工廠方法模式（Factory Method）、抽象工廠模式（Abstract Factory）、單例模式（Singleton）、建造者模式（Builder）、原型模式（Prototype）。

結(jié)構(gòu)型模式，共七種：適配器模式（Adapter）、裝飾器模式（Decorator）、代理模式（Proxy）、外觀模式（Facade）、橋接模式（Bridge）、組合模式（Composite）、享元模式（Flyweight）。

行為型模式，共十一種：策略模式（Strategy）、模板方法模式（Template Method）、觀察者模式（Observer）、迭代器模式（Iterator）、責任鏈模式（Chain Of Responsibility）、命令模式（Command）、備忘錄模式（Memento）、狀態(tài)模式（State）、訪問者模式（Visitor）、中介者模式（Mediator）、解釋器模式（Interpreter）。

其實還有兩類：并發(fā)型模式和線程池模式。用一個圖片來整體描述一下：

下面對23中這幾模式做一個簡介：

抽象工廠模式（AbstractFactory）：提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。
適配器模式（Adapter）：將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
橋接模式（Bridge）：將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化。
建造者模式（Builder）：將一個復雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
責任鏈模式（Chain of Responsibility）：為解除請求的發(fā)送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它。
命令模式（Command）：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志，以及支持可取消的操作。
組合模式（Composite）：將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。Composite使得客戶對單個對象和復合對象的使用具有一致性。
裝飾器模式（Decorator）：動態(tài)地給一個對象添加一些額外的職責。就擴展功能而言，Decorator模式比生成子類方式更為靈活。
外觀模式（Facade）：為子系統(tǒng)中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。
工廠方法模式（Factory Method）：定義一個用于創(chuàng)建對象的接口，讓子類決定將哪一個類實例化。FactoryMethod使一個類的實例化延遲到其子類。
享元模式（Flyweight）：運用共享技術(shù)有效地支持大量細粒度的對象。
解釋器模式（Interpreter）：給定一個語言,定義它的文法的一種表示，并定義一個解釋器,該解釋器使用該表示來解釋語言中的句子。
迭代器模式（Iterator）：提供一種方法順序訪問一個聚合對象中各個元素,而又不需暴露該對象的內(nèi)部表示。
中介者模式（Mediator）：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
備忘錄模式（Memento）：在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復到保存的狀態(tài)。
觀察者模式（Observer）：定義對象間的一種一對多的依賴關(guān)系,以便當一個對象的狀態(tài)發(fā)生改變時,所有依賴于它的對象都得到通知并自動刷新。
原型模式（Prototype）：用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這個原型來創(chuàng)建新的對象。
代理模式（Proxy）：為其他對象提供一個代理以控制對這個對象的訪問。
單例模式（Singleton）：保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。
狀態(tài)模式（State）：允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。對象看起來似乎修改了它所屬的類。
策略模式（Strategy）：定義一系列的算法,把它們一個個封裝起來,并且使它們可相互替換。本模式使得算法的變化可獨立于使用它的客戶。
模板方法模式（Template Method）：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。TemplateMethod使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。
訪問者模式（Visitor）：表示一個作用于某對象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。

?

二、設計模式的六大原則

總原則：開閉原則（Open Close Principle）

開閉原則就是說對擴展開放，對修改關(guān)閉。在程序需要進行擴展的時候，不能去修改原有的代碼，而是要擴展原有的代碼，實現(xiàn)一個熱插拔的效果。所以一句話概括就是：為了程序的擴展型好，易于維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類等，后面的具體設計中我們會提到點。

1、單一職責原則

不要存在多于一個導致類變更的原因，也就是說每個類應該實現(xiàn)單一的職責，如若不然，就應該把類拆分。

2、里氏替換原則（Liskov Substitution Principle）

里氏替換原則（Liskov Substitution Principle LSP）面向?qū)ο笤O計的基本原則之一。里氏替換原則中說，人和積累可以出現(xiàn)的地方，子類一定可以出現(xiàn)。LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏替換原則是對“開-閉”原則的補充。實現(xiàn)“開-閉”原則的關(guān)鍵步驟就是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體實現(xiàn)，所以里氏替換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范。

里氏替換原則中，子類對父類的方法盡量不要重寫和重載。因為父類代表了定義好的結(jié)構(gòu)，通過這個規(guī)范的接口與外界交互，子類不應該隨便破壞它。

3、依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內(nèi)容：面向接口編程，依賴于抽象而不依賴于具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。

4、接口隔離原則（Interface Segregation Principle）

這個原則的意思是：每個接口不存在子類用不到卻必須實現(xiàn)的方法，如果不然，就要將接口拆分。使用多個隔離的接口，比使用單個接口（多個接口方法集合到一個的接口）要好。

5、迪米特法則（最少知道原則）（Demeter Principle）

就是說：一個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多么復雜，都應該將邏輯封裝到方法的內(nèi)部，通過public方法提供給外部。這樣當依賴的類變化時，才能最小的影響該類。最小知道原則的另一個表達方式是：只給直接的朋友通信。類之間只要有耦合關(guān)系，就叫朋友關(guān)系。耦合分為依賴、關(guān)聯(lián)、聚合、組合等。我們稱出現(xiàn)的成員變量、方法參數(shù)、方法返回值中的類為直接朋友。局部變量、臨時變量則不是直接的朋友。我們要求陌生的類不要作為局部變量出現(xiàn)在類中。

6、合成復用原則（Composite Reuse Principle）

原則是盡量首先使用合成/聚合的方式，而不是使用繼承。

?

轉(zhuǎn)載于:https://www.cnblogs.com/cheney256/articles/9004988.html

總結(jié)

以上是生活随笔為你收集整理的【从入门到放弃】23种设计模式（1）：设计模式综述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。