設計模式之6個創建模式

創建型模式概述

創建型模式(Creational Pattern)對類的實例化過程進行了抽象，能夠將軟件模塊中對象的創建和對象的使用分離。為了使軟件的結構更加清晰，外界對于這些對象只需要知道它們共同的接口，而不清楚其具體的實現細節，使整個系統的設計更加符合單一職責原則。

創建型模式概述

創建型模式在創建什么(What)，由誰創建(Who)，何時創建(When)等方面都為軟件設計者提供了盡可能大的靈活性。創建型模式隱藏了類的實例的創建細節，通過隱藏對象如何被創建和組合在一起達到使整個系統獨立的目的。

一共包含6個模式

• 簡單工廠模式

• 工廠模式(Factory Method Pattern,多態工廠)
  

• 抽象工廠模式

• 單例模式

• 原型模式

• 建造者模式（Builder Pattern）

1簡單工廠模式

1.1優點

(1) 工廠類包含必要的判斷邏輯，可以決定在什么時候創建哪一個產品類的實例，客戶端可以免除直接創建產品對象的職責，

而僅僅“消費”產品，簡單工廠模式實現了對象創建和使用的分離。
(2) 客戶端無須知道所創建的具體產品類的類名，只需要知道具體產品類所對應的參數即可，

對于一些復雜的類名，通過簡單工廠模式可以在一定程度減少使用者的記憶量。
(3) 通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產品類，
在一定程度上提高了系統的靈活性。

1.2 缺點

(1) 由于工廠類集中了所有產品的創建邏輯，職責過重，一旦不能正常工作，整個系統都要受到影響。
(2) 使用簡單工廠模式勢必會增加系統中類的個數（ 引入了新的工廠類） ，增加了系統的復雜度和理解難度。
(3) 系統擴展困難，一旦添加新產品就不得不修改工廠邏輯，在產品類型較多時，有可能造工廠邏輯過于復雜，不利于系統的擴展和維護。
(4) 簡單工廠模式由于使用了靜態工廠方法，造成工廠角色無法形成基于繼承的等級結構。

1.3 場景

工廠類負責創建的對象比較少：由于創建的對象較少，不會造成工廠方法中的業務邏輯太過復雜。
客戶端只知道傳入工廠類的參數，對于如何創建對象不關心：客戶端既不需要關心創建細節，甚至連類名都不需要記住，

只需要知道類型所對應的參數。

1.4 類圖

Factory：工廠角色
Product：抽象產品角色

ConcreteProduct：具體產品角色

2.工廠模式

• 具體工廠類負責創建

2.1優點

在工廠方法模式中，工廠方法用來創建客戶所需要的產品，同時還向客戶隱藏了哪種具體產品類將被實例化這一細節，用戶只需要關心所需產品對應的工廠，無須關心創建細節，甚至無須知道具體產品類的類名。

基于工廠角色和產品角色的多態性設計是工廠方法模式的關鍵。它能夠使工廠可以自主確定創建何種產品對象，而如何創建這個對象的細節則完全封裝在具體工廠內部。工廠方法模式之所以又被稱為多態工廠模式，是因為所有的具體工廠類都具有同一抽象父類。

使用工廠方法模式的另一個優點是在系統中加入新產品時，無須修改抽象工廠和抽象產品提供的接口，無須修改客戶端，也無須修改其他的具體工廠和具體產品，而只要添加一個具體工廠和具體產品就可以了。這樣，系統的可擴展性也就變得非常好，完全符合“開閉原則”。

2.2缺點

在添加新產品時，需要編寫新的具體產品類，而且還要提供與之對應的具體工廠類，系統中類的個數將成對增加，在一定程度上增加了系統的復雜度，有更多的類需要編譯和運行，會給系統帶來一些額外的開銷。

由于考慮到系統的可擴展性，需要引入抽象層，在客戶端代碼中均使用抽象層進行定義，增加了系統的抽象性和理解難度，且在實現時可能需要用到DOM、反射等技術，增加了系統的實現難度。

2.3情景

一個類不知道它所需要的對象的類：在工廠方法模式中，客戶端不需要知道具體產品類的類名，只需要知道所對應的工廠即可，具體的產品對象由具體工廠類創建；客戶端需要知道創建具體產品的工廠類。

一個類通過其子類來指定創建哪個對象：在工廠方法模式中，對于抽象工廠類只需要提供一個創建產品的接口，而由其子類來確定具體要創建的對象，利用面向對象的多態性和里氏代換原則，在程序運行時，子類對象將覆蓋父類對象，從而使得系統更容易擴展。

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

2.4類圖

Product：抽象產品
ConcreteProduct：具體產品
Factory：抽象工廠
ConcreteFactory：具體工廠

3.抽象工廠模式

• 產品族
  

3.1優點

抽象工廠模式隔離了具體類的生成，使得客戶并不需要知道什么被創建。由于這種隔離，更換一個具體工廠就變得相對容易。所有的具體工廠都實現了抽象工廠中定義的那些公共接口，因此只需改變具體工廠的實例，就可以在某種程度上改變整個軟件系統的行為。另外，應用抽象工廠模式可以實現高內聚低耦合的設計目的，因此抽象工廠模式得到了廣泛的應用。

當一個產品族中的多個對象被設計成一起工作時，它能夠保證客戶端始終只使用同一個產品族中的對象。這對一些需要根據當前環境來決定其行為的軟件系統來說，是一種非常實用的設計模式。

增加新的具體工廠和產品族很方便，無須修改已有系統，符合“開閉原則”。

3.2缺點

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

開閉原則的傾斜性（增加新的工廠和產品族容易，增加新的產品等級結構麻煩）

3.3場景

一個系統不應當依賴于產品類實例如何被創建、組合和表達的細節，這對于所有類型的工廠模式都是重要的。

系統中有多于一個的產品族，而每次只使用其中某一產品族。

屬于同一個產品族的產品將在一起使用，這一約束必須在系統的設計中體現出來。

系統提供一個產品類的庫，所有的產品以同樣的接口出現，從而使客戶端不依賴于具體實現。

3.4類圖

AbstractFactory：抽象工廠
ConcreteFactory：具體工廠
AbstractProduct：抽象產品
Product：具體產品
4.單例模式

• 只有一個實例
  

4.1優點

提供了對唯一實例的受控訪問。因為單例類封裝了它的唯一實例，所以它可以嚴格控制客戶怎樣以及何時訪問它，并為設計及開發團隊提供了共享的概念。

由于在系統內存中只存在一個對象，因此可以節約系統資源，對于一些需要頻繁創建和銷毀的對象，單例模式無疑可以提高系統的性能。

允許可變數目的實例。我們可以基于單例模式進行擴展，使用與單例控制相似的方法來獲得指定個數的對象實例。

4.2缺點

由于單例模式中沒有抽象層，因此單例類的擴展有很大的困難。

單例類的職責過重，在一定程度上違背了“單一職責原則”。因為單例類既充當了工廠角色，提供了工廠方法，同時又充當了產品角色，包含一些業務方法，將產品的創建和產品的本身的功能融合到一起。

濫用單例將帶來一些負面問題，如為了節省資源將數據庫連接池對象設計為單例類，可能會導致共享連接池對象的程序過多而出現連接池溢出；現在很多面向對象語言(如Java、C#)的運行環境都提供了自動垃圾回收的技術，因此，如果實例化的對象長時間不被利用，系統會認為它是垃圾，會自動銷毀并回收資源，下次利用時又將重新實例化，這將導致對象狀態的丟失。

4.3情景

系統只需要一個實例對象，如系統要求提供一個唯一的序列號生成器，或者需要考慮資源消耗太大而只允許創建一個對象。

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

在一個系統中要求一個類只有一個實例時才應當使用單例模式。反過來，如果一個類可以有幾個實例共存，就需要對單例模式進行改進，使之成為多例模式。

4.4類圖

Singleton：單例

5.原型模式

• 復制對象
  

5.1優點

當創建新的對象實例較為復雜時，使用原型模式可以簡化對象的創建過程，通過一個已有實例可以提高新實例的創建效率。

可以動態增加或減少產品類。

原型模式提供了簡化的創建結構。

可以使用深克隆的方式保存對象的狀態。

5.2缺點

需要為每一個類配備一個克隆方法，而且這個克隆方法需要對類的功能進行通盤考慮，這對全新的類來說不是很難，但對已有的類進行改造時，不一定是件容易的事，必須修改其源代碼，違背了“開閉原則”。

在實現深克隆時需要編寫較為復雜的代碼。

5.3情景

創建新對象成本較大，新的對象可以通過原型模式對已有對象進行復制來獲得，如果是相似對象，則可以對其屬性稍作修改。

如果系統要保存對象的狀態，而對象的狀態變化很小，或者對象本身占內存不大的時候，也可以使用原型模式配合備忘錄模式來應用。相反，如果對象的狀態變化很大，或者對象占用的內存很大，那么采用狀態模式會比原型模式更好。

需要避免使用分層次的工廠類來創建分層次的對象，并且類的實例對象只有一個或很少的幾個組合狀態，通過復制原型對象得到新實例可能比使用構造函數創建一個新實例更加方便。

5.4類圖

Prototype：抽象原型類
ConcretePrototype：具體原型類
Client：客戶類
6.建造者模式

• 構建與表示分離

• 一步一步創建
  

6.1優點

在建造者模式中，客戶端不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象。

每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，用戶使用不同的具體建造者即可得到不同的產品對象。

可以更加精細地控制產品的創建過程。將復雜產品的創建步驟分解在不同的方法中，使得創建過程更加清晰，也更方便使用程序來控制創建過程。

增加新的具體建造者無須修改原有類庫的代碼，指揮者類針對抽象建造者類編程，系統擴展方便，符合“開閉原則”。

6.2缺點

建造者模式所創建的產品一般具有較多的共同點，其組成部分相似，如果產品之間的差異性很大，則不適合使用建造者模式，因此其使用范圍受到一定的限制。

如果產品的內部變化復雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大。

6.3情景

需要生成的產品對象有復雜的內部結構，這些產品對象通常包含多個成員屬性。

需要生成的產品對象的屬性相互依賴，需要指定其生成順序。

對象的創建過程獨立于創建該對象的類。在建造者模式中引入了指揮者類，將創建過程封裝在指揮者類中，而不在建造者類中。

隔離復雜對象的創建和使用，并使得相同的創建過程可以創建不同的產品。

6.4類圖

Builder：抽象建造者
ConcreteBuilder：具體建造者
Director：指揮者
Product：產品角色

參照

https://www.gitbook.com/book/quanke/design-pattern-java/details