340
技術社區[雲棲]
設計模式簡單總結
一 、創建型模式
1.1單例模式
設計原則：無
介紹：在整個應用中隻有一個對象
1.2簡單工廠
常用場景：需要在一堆產品中選擇其中一個產品
介紹：通過工廠類去創建產品，調用者不用直接去創建對象，並封裝了對象的創建細節。
設計原則：遵循單一職責 、違背開閉原則(生成不同對象，需要實現不同的工廠類，擴展性不好)
1.3工廠方法模式
常用場景：一種場景是希望工廠與產品的種類對客戶端保持透明，給客戶端提供一致的操作，另外一種是不同的工廠和產品可以提供客戶端不同的服務或功能
介紹：工廠方法模式又叫虛擬構造子模式或者多態性共存模式，工廠模式的用意是定義一個創建產品對象的工廠接口，將實際創建工作推遲到子類中
設計原則：單一指責，依賴倒置，開閉原則
1.4抽象工廠
常用場景：需要一個接口可以提供一個產品族，且不必知道產品的具體種類
介紹： 工廠方法模式與抽象工廠模式最大的區別在於，在工廠方法模式中，工廠創造的是一個產品，而在抽象工廠模式中，工廠創造的是一個產品族。
設計原則：單一指責，依賴倒置，開閉原則
1.5建造者模式
常用場景：需要構建一批構建過程相同但表示不同的產品，而構建過程非常複雜
介紹：建造模式是對象的創建模式。建造模式可以將一個產品的內部表象與產品的生成過程分割開來，從而可以使一個建造過程生成具有不同的內部表象的產品對象。
設計原則： 遵循單一職責、開閉原則
1.6 原型模式
常用場景：需要在運行時動態的創建指定實例種類的對象，或是需要複用其狀態
介紹：通過給出一個原型對象來指明所要創建的對象的類型，然後用複製這個原型對象的辦法創建出更多同類型的對象
設計原則：無
二、結構模式
2.1 代理模式
常用場景：需要修改或屏蔽某一個或若幹個類的部分功能，複用另外一部分功能，可使用靜態代理，若是需要攔截一批類中的某些方法，在方法的前後插入一些一致的操作，假設這些類有一致的接口，可使用JDK的動態代理，否則可使用cglib
介紹：代理模式給某一個對象提供一個代理對象，並由代理對象控製原有對象的引用
設計原則：體現功能複用
2.2適配器模式
、、
、、
常用場景：需要使用一個類的功能，但是該類的接口不符合使用場合要求的接口，可使用定製適配器，又或者是有一個接口定義的行為過多，則可以定義一個缺省適配器，讓子類選擇性的覆蓋適配器的方法
介紹：把一個類的接口變換成客戶端所期待的另一種結構，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作
原則： 遵循開閉原則、體現功能複用
2.3裝飾器模式
常用場景：一個類需要動態的添加功能，且這些功能可以相互疊加
介紹：裝飾器模式又名包裝模式，裝飾器模式用以對客戶端透明的方式擴展對象的功能，是繼承關係的一個替代方案
設計原則： 遵循迪米特、單一職責、開閉原則，破壞裏氏替換，體現功能複用
2.4 橋接模式
常用場景：一個對象有多個維度的變化，需要將這些維度抽離出來，讓其獨立變化
介紹：業務抽象角色引用業務實現角色，或者說業務抽象角色的部分實現是由業務實現角色實現完成的。
設計原則： 遵循單一職責、迪米特、開閉原則，體現功能複用
2.5 組合模式
常用場景：當有一個結構可以組合成樹形結構，且需要向客戶端提供一致的操作接口，使得客戶端操作忽略簡單元素與複雜元素
介紹：有時又叫做部分-整體模式。組合模式將對象組織到樹結構中，可以用來描述整體與部分的關係。組合模式可以使客戶端將單純元素與複合元素同等看待
設計原則： 遵循依賴倒置、開閉原則，破壞接口隔離
2.6 享元模式
常用場景：一些狀態相同的對象被大量的重複使用
介紹：享元模式以共享方式高效的支持大量的細粒度對象
2.7 門麵模式
常用場景：一個子係統需要對外提供服務
介紹：外部與子係統的通信（交互）必須通過統一的門麵對象進行
設計原則：遵循迪米特
三、行為型模式
3.1 觀察者模式
常用場景：需要將觀察者與被觀察者解耦或者是觀察者的種類不確定
介紹：又叫發布訂 閱模式，觀察者模式定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知所有觀察這對象，使它們能夠自動更新自己
設計原則：遵循迪米特、開閉原則
3.2 模板方法模式
常用場景：一批子類的功能有可提取的公共算法骨架
介紹：準備一個抽象類，將部分邏輯以抽象方法形式讓子類去實現，不同哦能的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現，這就是模板方法模式的用意
設計原則：破壞裏氏替換，體現功能複用
3.3 命令模式
常用場景：行為的請求者與行為的處理者耦合度過高
介紹：命令模式把一個請求或在操作封裝到一個對象中，命令模式允許係統使用不同的 請求把客戶端參數化，對請求排隊或者記錄請求日誌，可以提供命令的撤銷和恢複功能
介紹：命令模式把一個請求或在操作封裝到一個對象中，命令模式允許係統使用不同的 請求把客戶端參數化，對請求排隊或者記錄請求日誌，可以提供命令的撤銷和恢複功能
設計原則：遵循迪米特、開閉原則
3.4 狀態模式
常用場景：一個對象在多個狀態下行為不同，且這些狀態可互相轉換
介紹：狀態模式允許一個對象在其內部狀態改變的時候改變其行為，這個對象唉看上去就像是改變了它的類一樣
設計原則：遵循單一職責、依賴倒置、開閉原則
3.5責任鏈模式
常用場景：一個請求的處理需要多個對象當中的一個或幾個協作處理
介紹：很多對象是由每一個對象對其下家的引用而連接起來形成一條鏈，請求在這個鏈上傳遞，直到鏈上的某一個對象囧丁處理此請求，發出這個請求的客戶端並不知道鏈上的哪個對象最終處理了這個對象，這使得係統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任
設計原則：遵循迪米特
3.6 解釋器模式
常用場景：有一種語言被頻繁的使用
介紹：解釋器模式可以定義出其文法的一種表示，並同時提供一個解釋器。客戶端可以使用這個解釋器來解釋這個語言中的句子
設計原則：遵循單一職責
3.7中介者模式
常用場景：一個係列的對象交互關係十分複雜
介紹：中介者模式包裝了一係列對象相互作用的方式，使得這些對象不必相互明顯引用。從而使它們可以較鬆散地耦合
設計原則：遵循迪米特，破壞單一職責
3.8 訪問者模式
常用場景：作用於一個數據結構之上的操作經常變
介紹：訪問者模式的目地是封裝一些施加於某種數據結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數據結構則可以保持不變
設計原則：遵循傾斜的開閉原則
3.9策略模式
常用場景：算法或者策略需要經常替換
介紹：其用意是針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換
設計原則：遵循單一職責、依賴倒置、迪米特、開閉原則
3.10備忘錄模式
常用場景：需要在對象的外部保存該對象的內部狀態
介紹：又叫快照模式，備忘錄對象是一個用來存儲另外一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝性的條件下，將一個對象的狀態捕捉，並外部化存儲起來，從而可以在將來適合的時候把這個對象還原到存儲起來的狀態
設計原則：遵循迪米特、開閉原則
3.11迭代器模式
常用場景：需要迭代訪問一個聚合對象中的各個元素，且不暴露該聚合對象內部的表示
介紹：迭代器模式可以順序的訪問一個聚集中的元素而不必暴露聚集的內部表象
設計原則：遵循迪米特
最後更新：2017-05-22 15:34:01