設(shè)計模式詳解--創(chuàng)建型

創(chuàng)建型

共5種
工廠方法模式顽照、抽象工廠模式狼荞、建造者模式辽装、單例模式、原型模式

簡單工廠模式

概念

又稱為靜態(tài)工廠方法模式相味，在簡單工廠模式中拾积，可以根據(jù)參數(shù)的不同返回不同類的實例。簡單工廠專門定義一個類來負責創(chuàng)建其他類的實例丰涉，被創(chuàng)建的實例通常都具有共同的父類拓巧。簡單工廠不屬于GOF設(shè)計模式
優(yōu)點

客戶端可以免除直接創(chuàng)建產(chǎn)品對象的責任，而僅僅是“消費”產(chǎn)品
缺點

不符合開閉原則一死，系統(tǒng)擴展困難
使用場景 ★★★★☆
- 工廠類負責創(chuàng)建的對象比較少肛度。由于創(chuàng)建的對象較少，不會造成工廠方法中的業(yè)務(wù)邏輯太過復(fù)雜
- 客戶端只知道傳入工廠類的參數(shù)投慈，對于如何創(chuàng)建對象不關(guān)心承耿，更不關(guān)心創(chuàng)建的細節(jié)
  
  簡單工廠.png

創(chuàng)建型

工廠方法模式

概念

定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個類伪煤。工廠方法是一個類的實例化延遲到其子類
優(yōu)點
- 工廠方法用來創(chuàng)建客戶所需的產(chǎn)品加袋，向客戶隱藏了那個具體產(chǎn)品類將被實例化這一細節(jié)。用戶只需關(guān)心產(chǎn)品對應(yīng)的工廠抱既，無需關(guān)心創(chuàng)建細節(jié)
- 它能夠使工廠可以自主確定創(chuàng)建何種產(chǎn)品對象职烧，而如何創(chuàng)建這個對象的細節(jié)則完全封裝在具體工廠內(nèi)部
- 符合開閉原則，新增產(chǎn)品時防泵，無需修改抽象工廠和抽象產(chǎn)品提供的接口
缺點
- 新增產(chǎn)品時蚀之，需要編寫新的具體產(chǎn)品類，還需要提供與之對應(yīng)的具體工廠類捷泞。系統(tǒng)中類的個數(shù)將成對增加恬总，在一定程度上增加了系統(tǒng)的復(fù)雜度
- 由于考慮到系統(tǒng)的可擴展性，需要引入抽象層肚邢，在客戶端代碼中均使用抽象層進行定義壹堰，增加了系統(tǒng)的抽象度和理解難度
使用場景 ★★★★★
- 一個類不知道他所需要的對象的類：客戶端需要知道創(chuàng)建具體產(chǎn)品的工廠類
- 一個類通過其子類來指定創(chuàng)建哪個對象：在工廠方法模式中，對于抽象類只需要提供一個創(chuàng)建產(chǎn)品的接口骡湖，而由其子類來確定具體要創(chuàng)建的對象贱纠，利用面向?qū)ο蟮亩鄳B(tài)性和里氏替換原則，在程序運行時响蕴，子類對象將覆蓋父類對象谆焊，從而使系統(tǒng)更容易擴展
- 將創(chuàng)建對象的任務(wù)委托給多個工廠子類中的某一個，客戶端在使用時可以無需關(guān)心是哪一個工廠子類創(chuàng)建產(chǎn)品子類浦夷，需要時再動態(tài)指定辖试，可將具體工廠類的類名存儲在配置文件或數(shù)據(jù)庫中
  
  工廠方法.png

抽象工廠模式

概念

提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口辜王，而無需指定他們具體的類
優(yōu)點
- 易于交換產(chǎn)品系列：由于具體工廠類在一個應(yīng)用中只需要被實例化一次，這使得改變一個應(yīng)用的具體工廠變得非常容易罐孝，它只需要改變具體工廠即可使用不同的產(chǎn)品配置
- 它讓具體的創(chuàng)建實例過程與客戶端分離呐馆，客戶端是通過它們的抽象接口操縱實例，產(chǎn)品的具體類名也被具體工廠的實現(xiàn)分離莲兢，不會出現(xiàn)在客戶代碼中
缺點
- 在添加新的產(chǎn)品對象時汹来，難以擴展抽象工廠來生產(chǎn)新種類的產(chǎn)品，這是因為在抽象工廠角色中規(guī)定了所有可能被創(chuàng)建的產(chǎn)品集合改艇，要支持新種類的產(chǎn)品就意味著要對該接口進行擴展收班，而這將涉及對抽象工廠角色及其所有子類的修改，顯然會帶來較大的不變
使用場景★★★★★
- 系統(tǒng)中有多于一個的產(chǎn)品組谒兄，而每次只使用其中某一產(chǎn)品組摔桦。可以通過配置文件動態(tài)改變產(chǎn)品組承疲，如DB
  
  抽象工廠.png

建造者模式

概念

將一個復(fù)雜對象的構(gòu)建和它的表示分離邻耕，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。個人理解：類似于KFC套餐的概念纪隙，不同的套餐就是具體的建造實現(xiàn)類
優(yōu)點
- 客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié)，將產(chǎn)品本身和產(chǎn)品的創(chuàng)建過程解耦扛或，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象
- 每一個具體建造者都相互獨立绵咱，與其他具體建造者無關(guān)，可以方便的替代或新增
- 可以更加精細的控制產(chǎn)品的創(chuàng)建過程
- 新增建造者無需修改原有的代碼熙兔，符合開閉原則
缺點
- 建造者模式創(chuàng)建的產(chǎn)品一般具有較多的共同點悲伶，其組成部分相似。如果產(chǎn)品之間的差異很大住涉，則不適合使用建造者模式
- 如果產(chǎn)品內(nèi)部變化復(fù)雜麸锉，可能會導(dǎo)致需要定義很多具體建造者類來實現(xiàn)這種變化
使用場景★★☆☆☆
- 需要生成的產(chǎn)品對象的屬性相互依賴，需要指定其生成順序
- 對象的創(chuàng)建過程獨立于創(chuàng)建該對象的類
- 隔離復(fù)雜對象的創(chuàng)建和使用
  
  建造者.png

單例模式

概念

保證一個類僅有一個實例舆声，并提供一個訪問它的全局訪問點
優(yōu)點
- 提供了對唯一實例的受控訪問花沉，它可以嚴格控制客戶怎樣以及何時訪問它
- 節(jié)約系統(tǒng)資源
缺點
- 由于單例模式中沒有抽象層，因此單例類的擴展有很大困難
- 單例類職責過重媳握，一定程度上違背了”單一職責原則“碱屁。因為單例類既充當了工廠角色，提供工廠方法蛾找，同時又充當了產(chǎn)品角色娩脾，包含了一些業(yè)務(wù)方法，將產(chǎn)品的創(chuàng)建和產(chǎn)品本身的功能融合到一起
- 濫用會帶來負面問題打毛，如為了節(jié)省資源將數(shù)據(jù)庫連接池對象設(shè)計為單例類柿赊，可能會導(dǎo)致共享連接池對象的程序過多而出現(xiàn)連接池溢出
使用場景★★★★☆
- 系統(tǒng)只需要一個實例對象俩功。如系統(tǒng)要求提供一個唯一的序列號生成器
- 客戶調(diào)用類的單個實例只允許使用一個公共訪問點，除了該訪問點碰声，不能通過其他路徑訪問
  
  單例.png

原型模式

概念

用原型實例指定創(chuàng)建對象的種類诡蜓，并且通過拷貝這些原型創(chuàng)建新的對象
優(yōu)點
- 簡化復(fù)雜對象的創(chuàng)建過程
- 可以動態(tài)增加或減少產(chǎn)品類
- 可以使用深克隆的方式保存對象的狀態(tài)
缺點
- 需要為每一個類配備一個克隆方法，這個克隆方法需要對類的功能通盤考慮
- 實現(xiàn)深克隆時需要編寫較為復(fù)雜的代碼
使用場景★★★☆☆
- 創(chuàng)建對象成本較大的場景
  
  原型.png