下面分別對創建型模式下的各種具體模式進行講解。
先看例子： 工廠模式。
某功能的使用者只和接口打交道，不關心如何實現。這種情況下，肯定有壹個接口類，使用者使用接口；功能提供者繼承並實現接口。這利用了C++的多態特性。
既然使用者只關心接口，那麽沒有必要把子類直接給使用者，沒有必要讓使用者在代碼中直接new子類。如果這樣做，會把不必要的信息暴露給使用者，增加了信息的耦合。試想，如果使用者在很多地方都new了子類，那麽如果這些地方需要修改的話，怎麽改？只能壹個壹個地方改，改完還需要編譯，維護極其困難。
工廠模式是指，針對某壹功能接口，我們要新建壹個工廠類，此工廠類將接口子類名稱、接口子類的創建過程封裝起來，只返回壹個接口指針給接口的使用者。接口的實現類對使用者完全透明，高度解耦。這樣可以方便地切換接口的具體實現，而不影響上層功能使用者。拿 汽車 打比方，不管工廠生產 汽車 的流程是什麽，只要是 汽車 ，它的駕駛方法（人機接口）都類似。
顯而易見，工廠模式在使用者和實現者之間增加了壹個封裝層，這正印證了計算機行業中壹句名言：
典型的例子是：Qt中的數據庫模塊就利用了工廠模式，封裝了數據庫的底層實現。在保持數據庫用戶接口不變的情況下，通過更換數據庫驅動，可以實現數據庫類型無縫切換。
在需求趨於穩定時使用，需求不穩定時，不要過度設計，否則設計很容易被推翻，白費力氣。
從設計模式的本質來看，工廠模式：
先看例子： 抽象工廠模式。
由前面工廠模式可知，所有的“工廠”有壹個***同點：每個工廠都會提供創建對象的函數。 既然所有工廠都實現了同壹類功能，那麽我們可以為工廠抽象出壹個公***接口（虛基類），此接口定義了創建工廠子類的功能。 這種場景是否似曾相識？是的，工廠和工廠的功能接口構成了使用工廠模式的場景。即工廠本身也適用於工廠模式。 使用工廠模式來設計工廠，必然要寫壹個生產工廠的工廠。 生產工廠的工廠，返回值是工廠的抽象接口類，所以這種設計模式叫“抽象工廠模式”。其實，筆者覺得把這種設計模式叫做“工廠工廠模式”更容易理解。
如果只有壹個工廠就不要使用抽象工廠模式了，只有在工廠很多時，才使用抽象工廠模式。
需求不穩定時，不要過度設計，壹切都可能被推翻。 對於小的項目，不需要過度追求使用設計模式，架構的代碼最好只占整個項目代碼的壹小部分，否則就是主次顛倒，給自己找麻煩。 對於大的項目，在需求較穩定的情況下，為了提高可維護性、擴展性，可以考慮使用設計模式。 另外，抽象工廠模式有壹定的理解難度，要考慮妳設計的代碼，其他人是否能夠讀懂，簡單易懂也是需要考慮的方面。
所以，從設計模式的本質來看，
先看例子： 單例模式。
上面的例子都是允許壹個類被創建多次的。如果我們想要限制壹個類只被創建壹次，即只有壹個全局可訪問的實例（和C語言中的全局變量壹樣），例如應用程序對象，每個應用程序都應該只有壹個應用程序對象。此時應該怎麽編寫代碼呢？
答案還是封裝。把不想暴露出來的信息藏起來，把必須暴露的信息暴露出來。單例模式把類的構造函數設置成private私有訪問權限，限制外部無法通過new來創建實例。只能通過特定的接口來獲取實例指針。需要提及的是，封裝時需要考慮多線程安全的問題。
當壹個類需要有多個實例存在時，不使用單例模式。
從設計模式的本質上看，
具體的例子和寫法，可以參考菜鳥教程中的 建造者模式。
建造者模式的典型使用場景是快餐店的套餐搭配模型。 套餐由若幹個單個餐品組合而成。單個餐品又由不同的原材料構成。這種層層組合的樹形對象關系的應用場景下，為了創建頂層的對象，需要先壹層層的創建底層的對象，逐步向上，直到構造出根對象。 這種場景下，使用繼承可以將同類的對象關聯起來，使用組合可以將不同類型的對象組合起來。組合就是把不同對象放在壹塊內存中保存，作為壹個整體使用。
完全使用繼承來解決此類問題是非常不提倡的。設計模式理論中有壹個原則是：“少用繼承，多用組合”。因為繼承是壹種強耦合，組合是壹種松散的耦合。耦合不利於適應需求變化，是項目中的壹顆定時炸彈。
從設計模式的本質上看，
菜鳥教程中沒有提及的壹種設計模式是組合模式。具體內容可以參考： 第四節：組合模式和建築者模式詳解。
這裏簡單說明壹下，組合模式和建造者模式比較像，也是遵循樹形對象關系結構。和建造者模式相比，不同之處在於，子對象和父對象具有相同的類型。所以可以說，組合模式是簡單的建造者模式。
具體的使用場合和實例，見原型模式。
原型模式，在實際使用時可能用得不多。用壹句話描述其特點：
這種克隆是壹種內存中的復制行為，速度快，能充分利用已有對象的緩存數據，性能高。克隆出來的對象具有和原對象相同的屬性和行為，可以用來幫助原對象處理壹些事務。用壹句動漫中的詞匯來描述，“影分身”再合適不過了。
從設計模式的本質看，
下壹篇，我們將介紹結構型模式。