創(chuàng)建型

• 共5種
• 工廠方法模式、抽象工廠模式、建造者模式、單例模式、原型模式

簡單工廠模式

• 概念

  又稱為靜態(tài)工廠方法模式，在簡單工廠模式中，可以根據參數的不同返回不同類的實例。簡單工廠專門定義一個類來負責創(chuàng)建其他類的實例，被創(chuàng)建的實例通常都具有共同的父類。簡單工廠不屬于GOF設計模式

• 優(yōu)點

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

• 缺點

  不符合開閉原則，系統(tǒng)擴展困難

• 使用場景 ★★★★☆

  • 工廠類負責創(chuàng)建的對象比較少。由于創(chuàng)建的對象較少，不會造成工廠方法中的業(yè)務邏輯太過復雜

  • 客戶端只知道傳入工廠類的參數，對于如何創(chuàng)建對象不關心，更不關心創(chuàng)建的細節(jié)

    
    
    簡單工廠.png

創(chuàng)建型

工廠方法模式

• 概念

  定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個類。工廠方法是一個類的實例化延遲到其子類

• 優(yōu)點

  • 工廠方法用來創(chuàng)建客戶所需的產品，向客戶隱藏了那個具體產品類將被實例化這一細節(jié)。用戶只需關心產品對應的工廠，無需關心創(chuàng)建細節(jié)
  • 它能夠使工廠可以自主確定創(chuàng)建何種產品對象，而如何創(chuàng)建這個對象的細節(jié)則完全封裝在具體工廠內部
  • 符合開閉原則，新增產品時，無需修改抽象工廠和抽象產品提供的接口

• 缺點

  • 新增產品時，需要編寫新的具體產品類，還需要提供與之對應的具體工廠類。系統(tǒng)中類的個數將成對增加，在一定程度上增加了系統(tǒng)的復雜度
  • 由于考慮到系統(tǒng)的可擴展性，需要引入抽象層，在客戶端代碼中均使用抽象層進行定義，增加了系統(tǒng)的抽象度和理解難度

• 使用場景 ★★★★★

  • 一個類不知道他所需要的對象的類：客戶端需要知道創(chuàng)建具體產品的工廠類
  • 一個類通過其子類來指定創(chuàng)建哪個對象：在工廠方法模式中，對于抽象類只需要提供一個創(chuàng)建產品的接口，而由其子類來確定具體要創(chuàng)建的對象，利用面向對象的多態(tài)性和里氏替換原則，在程序運行時，子類對象將覆蓋父類對象，從而使系統(tǒng)更容易擴展

  • 將創(chuàng)建對象的任務委托給多個工廠子類中的某一個，客戶端在使用時可以無需關心是哪一個工廠子類創(chuàng)建產品子類，需要時再動態(tài)指定，可將具體工廠類的類名存儲在配置文件或數據庫中

    
    
    工廠方法.png

抽象工廠模式

• 概念

  提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定他們具體的類

• 優(yōu)點

  • 易于交換產品系列：由于具體工廠類在一個應用中只需要被實例化一次，這使得改變一個應用的具體工廠變得非常容易，它只需要改變具體工廠即可使用不同的產品配置
  • 它讓具體的創(chuàng)建實例過程與客戶端分離，客戶端是通過它們的抽象接口操縱實例，產品的具體類名也被具體工廠的實現分離，不會出現在客戶代碼中

• 缺點

  • 在添加新的產品對象時，難以擴展抽象工廠來生產新種類的產品，這是因為在抽象工廠角色中規(guī)定了所有可能被創(chuàng)建的產品集合，要支持新種類的產品就意味著要對該接口進行擴展，而這將涉及對抽象工廠角色及其所有子類的修改，顯然會帶來較大的不變

• 使用場景★★★★★

  • 系統(tǒng)中有多于一個的產品組，而每次只使用其中某一產品組?？梢酝ㄟ^配置文件動態(tài)改變產品組，如DB

    
    
    抽象工廠.png

建造者模式

• 概念

  將一個復雜對象的構建和它的表示分離，使得同樣的構建過程可以創(chuàng)建不同的表示。個人理解：類似于KFC套餐的概念，不同的套餐就是具體的建造實現類

• 優(yōu)點

  • 客戶端不必知道產品內部組成的細節(jié)，將產品本身和產品的創(chuàng)建過程解耦，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產品對象
  • 每一個具體建造者都相互獨立，與其他具體建造者無關，可以方便的替代或新增
  • 可以更加精細的控制產品的創(chuàng)建過程
  • 新增建造者無需修改原有的代碼，符合開閉原則

• 缺點

  • 建造者模式創(chuàng)建的產品一般具有較多的共同點，其組成部分相似。如果產品之間的差異很大，則不適合使用建造者模式
  • 如果產品內部變化復雜，可能會導致需要定義很多具體建造者類來實現這種變化

• 使用場景★★☆☆☆

  • 需要生成的產品對象的屬性相互依賴，需要指定其生成順序
  • 對象的創(chuàng)建過程獨立于創(chuàng)建該對象的類

  • 隔離復雜對象的創(chuàng)建和使用

    
    
    建造者.png

單例模式

• 概念

  保證一個類僅有一個實例，并提供一個訪問它的全局訪問點

• 優(yōu)點

  • 提供了對唯一實例的受控訪問，它可以嚴格控制客戶怎樣以及何時訪問它
  • 節(jié)約系統(tǒng)資源

• 缺點

  • 由于單例模式中沒有抽象層，因此單例類的擴展有很大困難
  • 單例類職責過重，一定程度上違背了”單一職責原則“。因為單例類既充當了工廠角色，提供工廠方法，同時又充當了產品角色，包含了一些業(yè)務方法，將產品的創(chuàng)建和產品本身的功能融合到一起
  • 濫用會帶來負面問題，如為了節(jié)省資源將數據庫連接池對象設計為單例類，可能會導致共享連接池對象的程序過多而出現連接池溢出

• 使用場景★★★★☆

  • 系統(tǒng)只需要一個實例對象。如系統(tǒng)要求提供一個唯一的序列號生成器

  • 客戶調用類的單個實例只允許使用一個公共訪問點，除了該訪問點，不能通過其他路徑訪問

    
    
    單例.png

原型模式

• 概念

  用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象

• 優(yōu)點

  • 簡化復雜對象的創(chuàng)建過程
  • 可以動態(tài)增加或減少產品類
  • 可以使用深克隆的方式保存對象的狀態(tài)

• 缺點

  • 需要為每一個類配備一個克隆方法，這個克隆方法需要對類的功能通盤考慮
  • 實現深克隆時需要編寫較為復雜的代碼

• 使用場景★★★☆☆

  • 創(chuàng)建對象成本較大的場景

    
    
    原型.png