設計模式及其應用場景
阿新 • • 發佈：2018-12-04
設計模式主要分三個型別：建立型、結構型和行為型。
建立型：
單例模式
保證一個類只有一個例項，並提供一個訪問它的全域性訪問點；
一個無狀態的類使用單例模式節省記憶體資源
抽象工廠
提供一個建立一系列相關和相互依賴物件的介面，而無須指定它們的具體類。
一系列相互依賴的物件有不同的具體實現。提供一種“封裝機制”來避免客戶程式和這種“多系列具體物件建立工作”的緊耦合。
工廠方法
定義一個用於建立物件的介面，讓子類決定例項化哪一個類，Factory Method使一個類的例項化延遲到了子類。
由於需求的變化，一個類的子類經常面臨著劇烈的變化，但他卻擁有比較穩定的介面。使用一種封裝機制來“隔離這種易變物件的變化”，工廠方法定義一個用於建立物件的介面，讓子類來確定建立哪一個具體類的物件，將物件的例項化延遲。
建造模式
將一個複雜物件的構建與他的表示相分離，使得同樣的構建過程可以建立不同的表示。
一個類的各個組成部分的具體實現類或者演算法經常面臨著變化，但是將他們組合在一起的演算法卻相對穩定。提供一種封裝機制 將穩定的組合演算法於易變的各個組成部分隔離開來。
原型模式
用原型例項指定建立物件的種類，並且通過拷貝這些原型來建立新的物件。
應用場景：用new建立一個物件需要非常繁瑣的資料準備或者許可權
行為型
迭代器模式
提供一個方法順序訪問一個聚合物件的各個元素，而又不需要暴露該物件的內部表示。
應用場景：迭代。
觀察者模式
定義物件間一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知自動更新。
應用場景： 某個例項的變化將影響其他多個物件。
模板方法
定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中，TemplateMethod使得子類可以不改變一個演算法的結構即可以重定義該演算法的某些特定步驟
應用場景：一個操作的步驟穩定，而具體細節的改變延遲到子類
命令模式
將一個請求封裝為一個物件，從而使你可以用不同的請求對客戶進行引數化，對請求排隊和記錄請求日誌，以及支援可撤銷的操作。
應用場景：將命令者與執行者完全解耦。
狀態模式
允許物件在其內部狀態改變時改變他的行為。物件看起來似乎改變了他的類。
應用場景：一個物件的內部狀態改變時，他的行為劇烈的變化。
策略模式
定義一系列的演算法，把他們一個個封裝起來，並使他們可以互相替換，本模式使得演算法可以獨立於使用它們的客戶。
職責鏈模式
China of Responsibility 職責鏈模式：使多個物件都有機會處理請求，從而避免請求的送發者和接收者之間的耦合關係
中介者模式
Mediator，中介者模式：用一箇中介物件封裝一些列的物件互動。
訪問者模式
Visitor，訪問者模式：表示一個作用於某物件結構中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用於這個元素的新操作。
直譯器模式
Interpreter，直譯器模式：給定一個語言，定義他的文法的一個表示，並定義一個直譯器，這個直譯器使用該表示來解釋語言中的句子。
備忘錄模式
Memento，備忘錄模式：在不破壞物件的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。
結構型
組合模式
Composite，組合模式：將物件組合成樹形結構以表示部分整體的關係，Composite使得使用者對單個物件和組合物件的使用具有一致性。
外觀模式
Facade，外觀模式：為子系統中的一組介面提供一致的介面，fa?ade提供了一高層介面，這個介面使得子系統更容易使用。
代理模式
Proxy，代理模式：為其他物件提供一種代理以控制對這個物件的訪問
介面卡模式
Adapter，介面卡模式：將一類的介面轉換成客戶希望的另外一個介面，Adapter模式使得原本由於介面不相容而不能一起工作那些類可以一起工作
裝飾模式
Decrator，裝飾模式：動態地給一個物件增加一些額外的職責，就增加的功能來說，Decorator模式相比生成子類更加靈活。
橋模式
Bridge，橋模式：將抽象部分與它的實現部分相分離，使他們可以獨立的變化。
享元模式
Flyweight，享元模式
23種設計模式要在這裡詳細的都說一遍內容實在太多了啊，推薦你一本好書《軟體祕笈：設計模式那點事》，裡面講解的23中設計模式例子很生動，容易理解，還有JDK中設計模式應用情況，看了收穫挺大的！百度裡面搜“設計模式”，第一條中設計模式百度百科中就有首推該圖書，瀏覽量在20幾萬以上的，不會錯的。