1. 程式人生 > >設計模式概念總結

設計模式概念總結

組件 適配器 .com 實現 固定 依賴 method req 簡單工廠模式

.https://www.cnblogs.com/zhili/p/DesignPatternSummery.html

1.單例模式(Singleton)

確保一個類只有一個實例,並提供一個全局訪問點

技術分享圖片

2.簡單工廠

技術分享圖片

優點:

  • 簡單工廠模式解決了客戶端直接依賴於具體對象的問題,客戶端可以消除直接創建對象的責任,而僅僅是消費產品。簡單工廠模式實現了對責任的分割
  • 簡單工廠模式也起到了代碼復用的作用

缺點:

  • 工廠類集中了所有產品創建邏輯,一旦沒辦法正常工作,整個系統都會受到影響
  • 系統擴展困難,一旦添加新產品就不得不修改工廠邏輯,這樣會造成工廠邏輯過於復雜

3.工廠方法模式

技術分享圖片

4.工廠方法模式(factory method)

定義一個用於創建對象的接口,讓子類決定實例化哪個類,工廠方法使一個類的實例化延遲其子類

技術分享圖片

5.抽象工廠模式(Abstract Factory)

提供了一個創建一系列相關或相互依賴對象的接口,而無需指定它們具體類。

技術分享圖片

優點:

抽象工廠模式將具體產品的創建延遲到具體工廠的子類中,這樣將對象的創建封裝起來,可以減少客戶端與具體產品類之間的依賴,從而使系統耦合低。這樣更有利於後期的維護發展

缺點:

抽象工廠模式很難支持新種類產品的變化,這是因為抽象工廠接口中已經確定了可以被創建的產品集合,如果需要添加新產品,此時就必須修改抽象工廠的接口,這樣涉及到抽象工廠類的以及所有子類的改變,這樣違背了“開發---關閉”原則。

6.建造者模式(Builder Parttern)

將一個復雜對象的構建與它的表示分離,使用同樣的構造過程可以構建不同的表示

技術分享圖片

建造模型要點

  • 在建造者模式中,指揮者是直接與客戶端打交道的,指揮者將客戶端創建產品的請求劃分為各個部件的建造要求,再將這些請求委托到具體建造者角色,具體建造角色是完成具體產品的構建工作,卻不為客戶所知道
  • 建造者模式主要用於“分步驟來構建一個復雜的對象”,其中“分步驟”是一個固定的組合過程,而復雜對象的各個部分是竟然變化的。
  • 產品不需要抽象類,由於建造者模式的創建出的最終產品可以差異很大,所以不大可能提取出一個抽象產品類
  • 由於建造者隱藏了具體產品的組裝過程,所以要改變一個產品的內部表示,只需要再實現一個具體的建造者就可以了,從而能很好的更好的應對產品組成組件的需求變化
  • 建造者模式解決的是“產品部分”的需要變化

7.原型模式(Prototype)

用原型實例指定創建對象的種類,並且通過拷貝這些原型創建新對象

技術分享圖片

優點:

  • 原型模式向客戶隱藏了創建新實例的復雜性
  • 原型模式允許動態增加或減少產品類
  • 原型模式簡化了實例的創建結構,工廠方法模式需要有一個與產品等級結構相同的等級結構,而原型模式不需要這樣
  • 產品類不需要事先確定產品的等級結構,因為原型模式適用於任何的等級結構

缺點:

  • 每個類必須匹配一個克隆方法
  • 匹配克隆方法需要對類的功能進行通盤考慮,這對於全新的類不是很難,但對於已有的類不一定容易,特別當一個類引用不支持串行化的間接對象,或者引用含有循環結構的時候。  

7.適配器模式(Adapter)

將一個類接口轉化成客戶希望的另外一個接口,Adapter模式使得原來由於接口不兼容而無法一起工作的類可以一起工作

適配器模式分為類適配器模式和對象適配器模式

類適配器模式

技術分享圖片

優點

1.可以在不修改原有代碼的基礎上來復用現有類,很好的符合“開閉原則”

2.可以重新定義Adaptee(被適配的類)的部分行為,因為在類適配器模式中,Adapter是Adaptee的子類

3.僅僅引用一個對象,並不需要額外的字段來引用Adapter實例(這個既是優點也是缺點)

缺點

1.用一個具體的Adapter類對Adaptee和Target進行匹配,當如果想要匹配一個類以及所有它的子類時,類的適配器模式就不能勝任了,因為類的適配器模式中沒有引用Adaptee的實例,光調用this.SpecificRequest方法並不能去調用它的對應子類的SpecificRequest方法

2.采用了“多繼承”的實現方式,帶來了不良的高耦合

對象適配器

技術分享圖片

優點

1.可以在不修改原有代碼的基礎上來復用現有類,很好的符合“開閉原則”。

2.采用了“對象組合”方式,更符合松耦合

缺點

1.使得重定義Adaptee的行為較困難,這需要生成Adaptee的子類並且使得Adaptee引用這個子類而不是引用Adaptee本身

適配器模式使用場景

1.系統需要復用現有類,而該類的接口不符合系統的需求

2.想要建立一個可重復使用的類,用於與一些彼此之間沒有太大關系的一些類,包括一些可能在將來引進的類一起工作

3.對於對象適配器模式,在設計裏需要改變多個已有子類的接口,如果使用類的適配器,就要針對每一個子類做一個適配器,而這不太實際。

8.橋接模式

將實現與抽象放在兩個不同的類中,使兩個層次可以獨立改變.橋接模式強調了接口對象提供的是一種算法

技術分享圖片

優點

1.抽象與實現與其實現解耦

2.抽象和實現可以獨立擴展,不會影響到對方

3.實現細節對客戶透明,對用於隱藏了具體的細節

缺點

增加了系統的復雜度

使用場景

1.如果一個系統需要在構建的抽象化角色和具體化角色之間添加更多的靈活性,避免在兩個層次之間建立靜態的聯系

2.設計要求實現化角色的任何改變不應當影響客戶端,或者實現化角色的改變對客戶端是完全透明的

3.需要跨越多個平臺的圖形和窗口系統上

4.一個類存在兩個獨立變化的維度,且兩個維度都需要進行擴展。

9.裝飾者模式(Decorator)

動態的給一個對象添加一些額外的職責,就添加功能來說,裝飾者模式比生成子類更加靈活

技術分享圖片

優點:

1.裝飾者模式和繼承的目的都是擴展對象的功能,但裝飾者模式比繼承更加靈活

2.通過使用不同的具體裝飾類以及這些類的排列組合,設計師可以創造出很多不同行為的組合

3.裝飾者模式有很好的可擴展性

缺點:

裝飾者模式會導致設計中出現許多小對象,如果過度使用,會讓程序變得更復雜,並且更多的對象會是的差錯變得困難,特別是這些對象看起來很像。

使用場景:

1.需要擴展一個類的功能或給一個類附加責任

2.需要動態的給一個對象增加功能,這些功能可以在動態的撤銷

3.需要增加由一些基本功能的排列組合而產生的大量的功能

設計模式概念總結