前言

根據菜鳥教程的目錄，我們首先來看看創建型模式。
創建型模式研究：

實際應用中通常有哪些不同的創建對象的場景；

在不同的場景下，如何更好地編寫創建對象的代碼。

主要研究構造函數。

下面分別對創建型模式下的各種具體模式進行講解。

---

1. 工廠模式

先看例子： 工廠模式。

使用場景

某功能的使用者只和接口打交道，不關心如何實現。這種情況下，肯定有一個接口類，使用者使用接口；功能提供者繼承并實現接口。這利用了C++的多態特性。

不好的做法

既然使用者只關心接口，那么沒有必要把子類直接給使用者，沒有必要讓使用者在代碼中直接new子類。如果這樣做，會把不必要的信息暴露給使用者，增加了信息的耦合。試想，如果使用者在很多地方都new了子類，那么如果這些地方需要修改的話，怎么改？只能一個一個地方改，改完還需要編譯，維護極其困難。

現成的方案 ：工廠模式

工廠模式是指，針對某一功能接口，我們要新建一個工廠類，此工廠類將接口子類名稱、接口子類的創建過程封裝起來，只返回一個接口指針給接口的使用者。接口的實現類對使用者完全透明，高度解耦。這樣可以方便地切換接口的具體實現，而不影響上層功能使用者。拿汽車打比方，不管工廠生產汽車的流程是什么，只要是汽車，它的駕駛方法（人機接口）都類似。

顯而易見，工廠模式在使用者和實現者之間增加了一個封裝層，這正印證了計算機行業中一句名言：

計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決。

典型的例子是：Qt中的數據庫模塊就利用了工廠模式，封裝了數據庫的底層實現。在保持數據庫用戶接口不變的情況下，通過更換數據庫驅動，可以實現數據庫類型無縫切換。

不適用的情況

• 如果只是一個單獨工作的類，沒有實現接口，就不需要用工廠模式。
• 如果一個類創建的地方不多，只有一兩次，那也沒有必要用工廠模式。可以在創建次數增多的時候，再考慮做優化。

小心使用

在需求趨于穩定時使用，需求不穩定時，不要過度設計，否則設計很容易被推翻，白費力氣。

本質

從設計模式的本質來看，工廠模式：

工廠模式，封裝了子類對象的創建過程，隱藏了子類，實現了使用者和實現者解耦。

---

2. 抽象工廠模式

先看例子： 抽象工廠模式。

使用場景

由前面工廠模式可知，所有的“工廠”有一個共同點：每個工廠都會提供創建對象的函數。
既然所有工廠都實現了同一類功能，那么我們可以為工廠抽象出一個公共接口（虛基類），此接口定義了創建工廠子類的功能。
這種場景是否似曾相識？是的，工廠和工廠的功能接口構成了使用工廠模式的場景。即工廠本身也適用于工廠模式。
使用工廠模式來設計工廠，必然要寫一個生產工廠的工廠。
生產工廠的工廠，返回值是工廠的抽象接口類，所以這種設計模式叫“抽象工廠模式”。其實，筆者覺得把這種設計模式叫做“工廠工廠模式”更容易理解。

不適用的情況

如果只有一個工廠就不要使用抽象工廠模式了，只有在工廠很多時，才使用抽象工廠模式。

小心使用

需求不穩定時，不要過度設計，一切都可能被推翻。
對于小的項目，不需要過度追求使用設計模式，架構的代碼最好只占整個項目代碼的一小部分，否則就是主次顛倒，給自己找麻煩。
對于大的項目，在需求較穩定的情況下，為了提高可維護性、擴展性，可以考慮使用設計模式。
另外，抽象工廠模式有一定的理解難度，要考慮你設計的代碼，其他人是否能夠讀懂，簡單易懂也是需要考慮的方面。

本質

所以，從設計模式的本質來看，

抽象工廠模式，封裝了工廠的創建過程。

---

3. 單例模式

先看例子： 單例模式。

使用場景

上面的例子都是允許一個類被創建多次的。如果我們想要限制一個類只被創建一次，即只有一個全局可訪問的實例（和C語言中的全局變量一樣），例如應用程序對象，每個應用程序都應該只有一個應用程序對象。此時應該怎么編寫代碼呢？

答案還是封裝。把不想暴露出來的信息藏起來，把必須暴露的信息暴露出來。單例模式把類的構造函數設置成private私有訪問權限，限制外部無法通過new來創建實例。只能通過特定的接口來獲取實例指針。需要提及的是，封裝時需要考慮多線程安全的問題。

不適用的情況

當一個類需要有多個實例存在時，不使用單例模式。

本質

從設計模式的本質上看，

單例模式，提供了一種限制實例個數的封裝方法，在項目中需要用到單例時，可以參考現成的方案。

---

4. 建造者模式

具體的例子和寫法，可以參考菜鳥教程中的 建造者模式。

使用場景

建造者模式的典型使用場景是快餐店的套餐搭配模型。
套餐由若干個單個餐品組合而成。單個餐品又由不同的原材料構成。這種層層組合的樹形對象關系的應用場景下，為了創建頂層的對象，需要先一層層的創建底層的對象，逐步向上，直到構造出根對象。
這種場景下，使用繼承可以將同類的對象關聯起來，使用組合可以將不同類型的對象組合起來。組合就是把不同對象放在一塊內存中保存，作為一個整體使用。

不好的做法

完全使用繼承來解決此類問題是非常不提倡的。設計模式理論中有一個原則是：“少用繼承，多用組合”。因為繼承是一種強耦合，組合是一種松散的耦合。耦合不利于適應需求變化，是項目中的一顆定時炸彈。

本質

從設計模式的本質上看，

建造者模式，提出了針對樹形的對象關系結構、包含不同種類子對象的、復雜對象的創建方法。封裝同類對象可以使用類繼承，封裝具體的子類實現，只暴露基類。封裝不同類型的子對象，使用組合。

菜鳥教程中沒有提及的一種設計模式是組合模式。具體內容可以參考：
第四節：組合模式和建筑者模式詳解。

這里簡單說明一下，組合模式和建造者模式比較像，也是遵循樹形對象關系結構。和建造者模式相比，不同之處在于，子對象和父對象具有相同的類型。所以可以說，組合模式是簡單的建造者模式。

---

5. 原型模式

具體的使用場合和實例，見原型模式。

原型模式，在實際使用時可能用得不多。用一句話描述其特點：

以現有對象為模板，克隆出新的對象。

這種克隆是一種內存中的復制行為，速度快，能充分利用已有對象的緩存數據，性能高。克隆出來的對象具有和原對象相同的屬性和行為，可以用來幫助原對象處理一些事務。用一句動漫中的詞匯來描述，“影分身”再合適不過了。

從設計模式的本質看，

原型模式，提出了使用創建對象副本，代替直接new類創建對象的一種方法。將對象的創建過程封裝起來，用對象拷貝來代替，可以避免不必要的資源浪費。

---

下一篇，我們將介紹結構型模式。

本文原創首發于微信公眾號Qt未來工程師。

總結

以上是生活随笔為你收集整理的设计模式（三）创建型模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。