各類設計模式的簡單介紹

設計模式的六大原則

• 單一職責原則
• 里氏替換原則
• 依賴倒置原則
• 接口隔離原則
• 迪米特原則
• 開閉原則

設計模式的分類

建立型模式

建立型模式：對對象實例化的抽象，經過採用抽象類所定義的接口，封裝了系統中對象如何建立，組合等信息。包括如下幾種設計模式

抽象工廠模式

優勢

• 分離了具體類
• 更容易在產品系列中進行轉換
• 提升了產品間一致性

缺點

• 難以支持新的產品等級結構
• 支持新的產品等級結構就要擴展原來的抽象工廠接口

適用場景

• 系統獨立於產品的建立，組成以及表示
• 系統配置成具備多個產品的系列
• 當要強調一系列相關的產品對象的設計便於進行聯合使用時
• 當提供一個產品類庫，而只想顯示它們的接口而不是實現時

應用舉例

在不少軟件系統中須要更換界面主題，要求界面中的按鈕，文本框，背景色等一塊兒發生改變時可使用抽象工廠模式進行設計

構建器模式

優勢

• 產品的內部表象能夠獨立變化
• 將構建代碼與表示代碼相分離，可使客戶端沒必要知道產品內部組成的細節

缺點

• 構建器模式建立的產品通常具備較多的共同點，其組成部分類似，若是產品之間差別性很大。則不適合使用構建器模式
• 若是產品的內部變化複雜，可能會致使須要定義不少具體建造者類來實現這種變化，致使系統變得很龐大

適用場景

建立複雜對象的算法獨立於組成對象的部分以及這些部分的集合方式 構造過程必須容許已構建對象有不一樣表示

應用舉例

在不少遊戲軟件中，地圖包括天空，地面背景等組成部分，人物角色包括人體，服裝，裝備等組成部分，可使用建造者模式對其進行設計，經過不一樣的具體建造者建立不一樣類型的地圖或人物

工廠方法模式

定義一個用於建立對象(產品)的接口，由子類決定實例化那個類的對象（ 產品）

優勢

• 沒有了將應用程序綁定到代碼中的要求，代碼只處理接口，所以可使用任何實現了接口的類
• 容許子類提供對象的擴展版本
• 符合迪米特法則，依賴倒置原則，里氏替換原則

缺點

• 須要Creator和相應的子類做爲工廠方法的載體，若是應用模型確實須要creator的子類存在，則很好，不然須要增長一個類層次

適用場景

• 當一個類不知道他所建立的產品的具體是那個子類時
• 當建立對象的過程但願延緩到子類中進行時
• 類但願子類指定他要建立的對象

應用舉例

Windows的COM組件與MFC

原型模式

指定建立對象的種類，而且經過拷貝這些原型建立新的對象，以一個已有的對象做爲原型，經過他來建立新對象

優勢

• 能夠在容許時添加或刪除產品
• 原型模式提供簡化的建立結構
• 具備給一個應用軟件加載新功能的能力
• 產品類不須要非得由任何實現肯定的等級結構

缺點

每個類必須配備一個克隆方法

適用場景

• 在運行時，指定須要實例化的類，例如動態載入，避免構建與產品的類層次結構類似的共產類層次結構
• 當類的實例是僅有的一些不一樣狀態組合

單例模式

一個類只有一個實例

優勢

• 對單個實例的受控制訪問
• 名稱空間減小
• 容許改進操做和表示
• 容許可變數目的實例
• 比類操做更靈活

缺點

單例類的擴展有很大困難，且職責太重，這在必定程度上違背了單一職責原則

適用場景

只有一個類實例

應用舉例

逐漸生成器

結構型模式

主要用於如何組合已有的類和對象以得到更大的結構，它採用繼承機制組合接口來實現，以提供 統一的外部試圖或新的功能

適配器模式

將一個類的接口轉換成客戶但願的另一個接口，Adapter模式使得本來的接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做

優勢

• 容許兩個或多個不兼容的對象進行交互和通訊
• 提升已有功能的重複適用
• 增長了類的透明度
• 靈活性

缺點

過多的適用適配器會讓系統很是凌亂，不易總體進行把握

適用場景

• 要使用已有的類，而該類接口與所需的接口並不匹配
• 要建立可重複使用的類，該類能夠與不相干或未知類進行協助，即類之間不須要兼容接口
• 要在一個不一樣於已知接口的接口環境重使用對象
• 必需要進行多個源之間的接口轉換的時候

應用舉例

在.Net重有一個類庫已經實現的，很是重要的適配器——Data Adapter

橋接模式

將一個輔助的組件分紅兩個獨立的但又相關的繼承層次結構

優勢

• 能夠將接口與是實現相分離
• 提升可擴展性
• 對客戶端隱藏了實現細節

缺點

• 增長了系統的理解和設計難度
• 要求正確的識別出系統重兩個獨立變化的維度，所以其使用範圍有必定的侷限性

適用場景

• 想避免在抽象及其實現之間存在永久的綁定
• 抽象及其實現可使用子類進行擴展
• 抽象的實現被改動應該對客戶端沒有影響

組合模式

將對象組合成樹型結構以表示「部分-總體」的層次結構

優勢

• 清楚的定義分層次的複雜對象，表示對象的所有或部分層次
• 使得增長新構件 更容易了了
• 提升告終構的靈活性和可管理的接口

缺點

使設計變得更加抽象。若是對象的業務規則很複雜，則實現組合模式具備很大的挑戰性，並且不是全部的方法都與葉子對象子類有關聯

適用場景

• 想表示對象的部分--總體層次結構
• 但願用戶忽略組合對象與單個對象的不一樣，用戶將統一的使用組合結構重的全部對象
• 結構能夠具備任何級別的複雜性，並且是動態的

應用舉例

部分、總體場景如樹型菜單，文件，文件夾的管理

裝飾模式

動態的給對象添加一些額外的責任，就增長功能來講，裝飾比生成子類更爲靈活

優勢

• 比靜態繼承具備更大的靈活性
• 簡化代碼
• 改進對象的擴展性，用戶能夠經過編寫新的類來作出改變
• 裝飾類和被裝飾類能夠獨立發展，不會相互耦合

缺點

多層裝飾比較複雜

適用場景

• 想要在單個對象動態而且透明的添加責任，而這樣不會影響其餘對象
• 想要在之後可能要修改的對象重添加責任
• 當沒法經過靜態子類化實現擴展時

外觀模式

爲子系統重的一組接口提供一個統一的接口，外觀模式經過一個高層接口隔離了外部系統與子系統間複雜的交互過程，使得複雜系統的子系統更容易使用

優勢

• 在不減小系統所提供的選項的狀況下，爲複雜系統提供了簡單的接口
• 客戶端屏蔽了子系統組件
• 提升了子系統和其客戶端之間的弱耦合度
• 將客戶端請求轉發後可以處理這些請求的子系統

缺點

• 不能很好的限制客戶使用子系統類，若是對客戶訪問子系統作太多的限制，則減小了可變性和靈活性
• 在不引入抽象外觀類的狀況下，增長新的子系統可能須要修改外觀類或客戶端的源代碼，違背了開閉原則

適用場景

• 爲一個複雜子系統提供一個簡單接口時
• 客戶程序與抽象類的實現之間存在着很大的依賴性
• 構建一個層次結構的子系統時，適用Facade模式定義子系統中每層的入口點，若是子系統之間是相互依賴的，你可讓他們僅經過Facade進行通訊，從而簡化了他們之間的依賴關係

享元模式

經過共享對象減小系統中低等級的，詳細的對象數目

優勢

• 減小了要處理的對象數目
• 若是對象可以持續，能夠減小內存和存儲設備

缺點

• 使得應用程序在某種程度上來講更加複雜化了
• 爲了使對象能夠共享，享元模式須要將享元對象的狀態外部化，而讀取外部狀態使得運行時間變長

適用場景

• 應用程序使用大量的對象
• 因爲對象數目巨大，致使很高的存儲開銷
• 應用程序不依賴於對象的身份

代理模式

爲控制初始對象的訪問，提供了一個代理或者佔位符對象

優勢

• 遠程代理能夠隱藏對象位於不一樣的地址空間的事實
• 虛擬代理能夠執行優化操做

缺點

• 請求的處理速度變慢
• 實現代理模式須要額外的工做，從而增長了系統實現的複雜度

適用場景

• 當須要爲了一個對象在不一樣的地址空間提供局部的表明時
• 當須要建立開銷很是大的對象時

應用舉例

防火牆代理---保護目標不讓惡意用戶靠近

行爲型模型

從大量的實際行動中歸納出來做爲行爲的理論抽象、基本框架和標準，該類模式主要用於對象之間的職責及其提供的服務的分配，他不只描述對象或類的模式，還描述它們之間的通訊模式

責任鏈模式

在系統中創建一個鏈，消息能夠首先接收到他的級別被處理，或者定位到能夠處理他的對象

優勢

• 下降耦合度
• 增長向對象指定責任的靈活性

適用場景

• 多個對象能夠處理一個請求，而其處理器倒是未知的
• 能夠動態指定可以處理請求的對象集

命令模式

在對象中封裝請求，保存命令並傳遞給方法以及任何其餘對象同樣返回該命令

優勢

• 添加新命令不用修改已有類
• 將操做對象與知道如何完成操做的對象相分離

適用場景

• 想要經過要執行的動做來參數化對象
• 在不一樣的時間指定、排序以及執行請求

解釋器模式

解釋定義其語法表示的語言

優勢

• 容易修改並擴展語法
• 容易實現語法

適用場景

• 語言的語法比較簡單
• 效率並非最主要的問題

迭代器模式

提供一種方法順序的訪問一個聚合對象中的各個元素，而又不暴露改對象的內部表示

優勢

• 支持集合的不一樣遍歷
• 簡化集合接口

適用場景

• 在不開放集合內部對象表示的前提下訪問集合對象內容
• 支持記號個對象的多重遍歷
• 爲遍歷集合中的不一樣結構提供了統一的接口

備忘錄模式

保持對象狀態的「快照」，在不向外界公開其內容的狀況下返回到它的最初狀態

優勢

• 保持封裝完整
• 簡化了返回到初始狀態所需的操做

適用場景

• 必須保存對象的快照
• 適用直接接口來得到狀態有可能會公開對象的實現細節，從而破壞對象的封裝性

觀察者模式

爲組件向相關接收方廣播消息提供了靈活的方法

優勢

• 抽象了主體與Observer 之間的耦合關係
• 支持廣播方式的通訊

####適用場景

• 對一個對象的修改涉及其餘對象的修改，而不知道有多少對象須要修改
• 對象應該能在不設置對象標識的狀況下通知其餘對象

狀態模式

容許對象在內部狀態變化時變動其行爲，而且修改其類

優勢

• 定位指定狀態的行爲，並根據不一樣的狀態來劃分行爲

適用場景

• 對象行爲依賴於其狀態，且對象必須在運行時根據其狀態修改行爲
• 操做具備大量以及多部份組成的取決於對象狀態的條件語句

策略模式

定義了一組用來表示可能行爲集合的類

優勢

• 另外一種子類化方法
• 在類自身中定義行爲，減小條件語句
• 更容易擴展模型

適用場景

• 許多相關類只是在行文方面有所區別
• 須要算法的不一樣變體
• 算法使用客戶端未知的數據

模板方法模式

提供了在不重寫方法的前提下容許子類重載部分方法的方法

優勢

• 代碼使用

適用場景

• 想要一次實現算法的不變部分，適用子類實現算法的可變行爲
• 子類間通用行爲須要分解，定位到通用類，能夠避免代碼重複問題

訪問者模式

提供了一種方便的，可維護的方法來表示在對象結構元素上進行的操做。改模式容許在不改變操做元素的類的前提下定義一個新操做

優勢

• 容易添加新操做
• 集中相關操做而且排除不相關操做

適用場景

• 定義對象結構的類不多被修改，但想要在此結構上定義新的操做
• 對象結構包含許多具備不一樣接口的對象類，而且想要對這些依賴於具體的類的對象進行操做

中介者模式

經過引入一個可以管理對象間消息分佈的對象，簡化系統中對象的通訊

優勢

• 取出對象間的影響
• 簡化對象間的協議
• 集中化控制

適用場景

• 對象集合須要一個定義但複雜的方式進行通訊
• 想要在不使用子類的狀況下自定義分佈在幾個對象間的行爲

本文由博客一文多發平臺 OpenWrite 發佈！