GoF的23種設計模式之創建型模式的特點和分類

創建型模式的主要關注點是“怎樣創建對象？”，它的主要特點是“將對象的創建與使用分離”。這樣可以降低系統的耦合度，使用者不需要關注對象的創建細節，對象的創建由相關的工廠來完成。就像我們去商場購買商品時，不需要知道商品是怎么生產出來一樣，因為它們由專門的廠商生產。

創建型模式分為以下幾種。

• 單例（Singleton）模式：某個類只能生成一個實例，該類提供了一個全局訪問點供外部獲取該實例，其拓展是有限多例模式。
• 原型（Prototype）模式：將一個對象作為原型，通過對其進行復制而克隆出多個和原型類似的新實例。
• 工廠方法（FactoryMethod）模式：定義一個用於創建產品的接口，由子類決定生產什么產品。
• 抽象工廠（AbstractFactory）模式：提供一個創建產品族的接口，其每個子類可以生產一系列相關的產品。
• 建造者（Builder）模式：將一個復雜對象分解成多個相對簡單的部分，然后根據不同需要分別創建它們，最后構建成該復雜對象。

單列模式

在有些系統中，為了節省內存資源、保證數據內容的一致性，對某些類要求只能創建一個實例，這就是所謂的單例模式。

單例模式的定義與特點

單例（Singleton）模式的定義：指一個類只有一個實例，且該類能自行創建這個實例的一種模式。例如，Windows 中只能打開一個任務管理器，這樣可以避免因打開多個任務管理器窗口而造成內存資源的浪費，或出現各個窗口顯示內容的不一致等錯誤。

在計算機系統中，還有 Windows 的回收站、操作系統中的文件系統、多線程中的線程池、顯卡的驅動程序對象、打印機的后台處理服務、應用程序的日志對象、數據庫的連接池、網站的計數器、Web 應用的配置對象、應用程序中的對話框、系統中的緩存等常常被設計成單例。

單例模式有 3 個特點：

1. 單例類只有一個實例對象；
2. 該單例對象必須由單例類自行創建；
3. 單例類對外提供一個訪問該單例的全局訪問點；

單例模式的結構與實現

單例模式是設計模式中最簡單的模式之一。通常，普通類的構造函數是公有的，外部類可以通過“new 構造函數()”來生成多個實例。但是，如果將類的構造函數設為私有的，外部類就無法調用該構造函數，也就無法生成多個實例。這時該類自身必須定義一個靜態私有實例，並向外提供一個靜態的公有函數用於創建或獲取該靜態私有實例。

下面來分析其基本結構和實現方法。

1. 單例模式的結構
單例模式的主要角色如下。

• 單例類：包含一個實例且能自行創建這個實例的類。
• 訪問類：使用單例的類。

其結構如圖1所示。

圖1單例模式的結構圖

2. 單例模式的實現
Singleton 模式通常有兩種實現形式。
第 1 種：懶漢式單例
該模式的特點是類加載時沒有生成單例，只有當第一次調用 getlnstance 方法時才去創建這個單例。

第 2 種：餓漢式單例
該模式的特點是類一旦加載就創建一個單例，保證在調用 getInstance 方法之前單例已經存在了。

單例模式的應用場景

前面分析了單例模式的結構與特點，以下是它通常適用的場景的特點。

• 在應用場景中，某類只要求生成一個對象的時候，如一個班中的班長、每個人的身份證號等。
• 當對象需要被共享的場合。由於單例模式只允許創建一個對象，共享該對象可以節省內存，並加快對象訪問速度。如 Web 中的配置對象、數據庫的連接池等。
• 當某類需要頻繁實例化，而創建的對象又頻繁被銷毀的時候，如多線程的線程池、網絡連接池等。

單例模式的擴展

單例模式可擴展為有限的多例（Multitcm）模式，這種模式可生成有限個實例並保存在 ArmyList 中，客戶需要時可隨機獲取，其結構圖如圖2所示。

圖2有限的多例模式的結構圖

 

原型模式

在有些系統中，存在大量相同或相似對象的創建問題，如果用傳統的構造函數來創建對象，會比較復雜且耗時耗資源，用原型模式生成對象就很高效，就像孫悟空拔下猴毛輕輕一吹就變出很多孫悟空一樣簡單。

原型模式的定義與特點

原型（Prototype）模式的定義如下：用一個已經創建的實例作為原型，通過復制該原型對象來創建一個和原型相同或相似的新對象。在這里，原型實例指定了要創建的對象的種類。用這種方式創建對象非常高效，根本無須知道對象創建的細節。例如，Windows 操作系統的安裝通常較耗時，如果復制就快了很多。

原型模式的結構與實現

由於 Java 提供了對象的 clone() 方法，所以用 Java 實現原型模式很簡單。
1. 模式的結構
原型模式包含以下主要角色。

1. 抽象原型類：規定了具體原型對象必須實現的接口。
2. 具體原型類：實現抽象原型類的 clone() 方法，它是可被復制的對象。
3. 訪問類：使用具體原型類中的 clone() 方法來復制新的對象。

其結構圖如圖1所示。

圖1原型模式的結構圖

2. 模式的實現
原型模式的克隆分為淺克隆和深克隆，Java 中的 Object 類提供了淺克隆的 clone() 方法，具體原型類只要實現 Cloneable 接口就可實現對象的淺克隆，這里的 Cloneable 接口就是抽象原型類。

原型模式的應用場景

原型模式通常適用於以下場景。

• 對象之間相同或相似，即只是個別的幾個屬性不同的時候。
• 對象的創建過程比較麻煩，但復制比較簡單的時候。

原型模式的擴展

原型模式可擴展為帶原型管理器的原型模式，它在原型模式的基礎上增加了一個原型管理器 PrototypeManager 類。該類用 HashMap 保存多個復制的原型，Client 類可以通過管理器的 get(String id) 方法從中獲取復制的原型。其結構圖如圖2所示。

帶原型管理器的原型模式的結構圖

圖2帶原型管理器的原型模式的結構圖

 

工廠方法模式

在現實生活中社會分工越來越細，越來越專業化。各種產品有專門的工廠生產，徹底告別了自給自足的小農經濟時代，這大大縮短了產品的生產周期，提高了生產效率。同樣，在軟件開發中能否做到軟件對象的生產和使用相分離呢？能否在滿足“開閉原則”的前提下，客戶隨意增刪或改變對軟件相關對象的使用呢？

模式的定義與特點

工廠方法（FactoryMethod）模式的定義：定義一個創建產品對象的工廠接口，將產品對象的實際創建工作推遲到具體子工廠類當中。這滿足創建型模式中所要求的“創建與使用相分離”的特點。

我們把被創建的對象稱為“產品”，把創建產品的對象稱為“工廠”。如果要創建的產品不多，只要一個工廠類就可以完成，這種模式叫“簡單工廠模式”，它不屬於 GoF 的 23 種經典設計模式，它的缺點是增加新產品時會違背“開閉原則”。

這里介紹的“工廠方法模式”是對簡單工廠模式的進一步抽象化，其好處是可以使系統在不修改原來代碼的情況下引進新的產品，即滿足開閉原則。

工廠方法模式的主要優點有：

• 用戶只需要知道具體工廠的名稱就可得到所要的產品，無須知道產品的具體創建過程；
• 在系統增加新的產品時只需要添加具體產品類和對應的具體工廠類，無須對原工廠進行任何修改，滿足開閉原則；

其缺點是：每增加一個產品就要增加一個具體產品類和一個對應的具體工廠類，這增加了系統的復雜度。

模式的結構與實現 

工廠方法模式由抽象工廠、具體工廠、抽象產品和具體產品等4個要素構成。這里來分析其基本結構和實現方法。
1. 模式的結構
工廠方法模式的主要角色如下。

1. 抽象工廠（Abstract Factory）：提供了創建產品的接口，調用者通過它訪問具體工廠的工廠方法 newProduct() 來創建產品。
2. 具體工廠（ConcreteFactory）：主要是實現抽象工廠中的抽象方法，完成具體產品的創建。
3. 抽象產品（Product）：定義了產品的規范，描述了產品的主要特性和功能。
4. 具體產品（ConcreteProduct）：實現了抽象產品角色所定義的接口，由具體工廠來創建，它同具體工廠之間一一對應。

 其結構圖如圖1所示。

圖1工廠方法模式的結構圖

模式的應用場景

工廠方法模式通常適用於以下場景。

• 客戶只知道創建產品的工廠名，而不知道具體的產品名。如 TCL 電視工廠、海信電視工廠等。
• 創建對象的任務由多個具體子工廠中的某一個完成，而抽象工廠只提供創建產品的接口。
• 客戶不關心創建產品的細節，只關心產品的品牌。

模式的擴展

當需要生成的產品不多且不會增加，一個具體工廠類就可以完成任務時，可刪除抽象工廠類。這時工廠方法模式將退化到簡單工廠模式，其結構圖如圖2所示。

圖2簡單工廠模式的結構圖

 

抽象工廠模式

前面介紹的工廠方法模式中考慮的是一類產品的生產，如畜牧場只養動物、電視機廠只生產電視機。

同種類稱為同等級，也就是說：工廠方法模式只考慮生產同等級的產品，但是在現實生活中許多工廠是綜合型的工廠，能生產多等級（種類） 的產品，如農場里既養動物又種植物，電器廠既生產電視機又生產洗衣機或空調。

下面要介紹的抽象工廠模式將考慮多等級產品的生產，將同一個具體工廠所生產的位於不同等級的一組產品稱為一個產品族，圖 1 所示的是海爾工廠和 TCL 工廠所生產的電視機與空調對應的關系圖。

電器工廠的產品等級與產品族

圖1 電器工廠的產品等級與產品族

模式的定義與特點

抽象工廠（AbstractFactory）模式的定義：是一種為訪問類提供一個創建一組相關或相互依賴對象的接口，且訪問類無須指定所要產品的具體類就能得到同族的不同等級的產品的模式結構。

抽象工廠模式是工廠方法模式的升級版本，工廠方法模式只生產一個等級的產品，而抽象工廠模式可生產多個等級的產品。

使用抽象工廠模式一般要滿足以下條件。

• 系統中有多個產品族，每個具體工廠創建同一族但屬於不同等級結構的產品。
• 系統一次只可能消費其中某一族產品，即同族的產品一起使用。

抽象工廠模式除了具有工廠方法模式的優點外，其他主要優點如下。

• 可以在類的內部對產品族中相關聯的多等級產品共同管理，而不必專門引入多個新的類來進行管理。
• 當增加一個新的產品族時不需要修改原代碼，滿足開閉原則。

其缺點是：當產品族中需要增加一個新的產品時，所有的工廠類都需要進行修改。

模式的結構與實現

抽象工廠模式同工廠方法模式一樣，也是由抽象工廠、具體工廠、抽象產品和具體產品等 4 個要素構成，但抽象工廠中方法個數不同，抽象產品的個數也不同。現在我們來分析其基本結構和實現方法。
1. 模式的結構
抽象工廠模式的主要角色如下。

1. 抽象工廠（Abstract Factory）：提供了創建產品的接口，它包含多個創建產品的方法 newProduct()，可以創建多個不同等級的產品。
2. 具體工廠（Concrete Factory）：主要是實現抽象工廠中的多個抽象方法，完成具體產品的創建。
3. 抽象產品（Product）：定義了產品的規范，描述了產品的主要特性和功能，抽象工廠模式有多個抽象產品。
4. 具體產品（ConcreteProduct）：實現了抽象產品角色所定義的接口，由具體工廠來創建，它 同具體工廠之間是多對一的關系。

抽象工廠模式的結構圖如圖 2 所示。

圖2 抽象工廠模式的結構圖

2. 模式的實現
從圖 2 可以看出抽象工廠模式的結構同工廠方法模式的結構相似，不同的是其產品的種類不止一個，所以創建產品的方法也不止一個。

模式的應用場景

抽象工廠模式最早的應用是用於創建屬於不同操作系統的視窗構件。如 java 的 AWT 中的 Button 和 Text 等構件在 Windows 和 UNIX 中的本地實現是不同的。

抽象工廠模式通常適用於以下場景：

1. 當需要創建的對象是一系列相互關聯或相互依賴的產品族時，如電器工廠中的電視機、洗衣機、空調等。
2. 系統中有多個產品族，但每次只使用其中的某一族產品。如有人只喜歡穿某一個品牌的衣服和鞋。
3. 系統中提供了產品的類庫，且所有產品的接口相同，客戶端不依賴產品實例的創建細節和內部結構。

模式的擴展

抽象工廠模式的擴展有一定的“開閉原則”傾斜性：

1. 當增加一個新的產品族時只需增加一個新的具體工廠，不需要修改原代碼，滿足開閉原則。
2. 當產品族中需要增加一個新種類的產品時，則所有的工廠類都需要進行修改，不滿足開閉原則。

另一方面，當系統中只存在一個等級結構的產品時，抽象工廠模式將退化到工廠方法模式。

 

建造者模式

在軟件開發過程中有時需要創建一個復雜的對象，這個復雜對象通常由多個子部件按一定的步驟組合而成。例如，計算機是由 OPU、主板、內存、硬盤、顯卡、機箱、顯示器、鍵盤、鼠標等部件組裝而成的，采購員不可能自己去組裝計算機，而是將計算機的配置要求告訴計算機銷售公司，計算機銷售公司安排技術人員去組裝計算機，然后再交給要買計算機的采購員。

生活中這樣的例子很多，如游戲中的不同角色，其性別、個性、能力、臉型、體型、服裝、發型等特性都有所差異；還有汽車中的方向盤、發動機、車架、輪胎等部件也多種多樣；每封電子郵件的發件人、收件人、主題、內容、附件等內容也各不相同。

以上所有這些產品都是由多個部件構成的，各個部件可以靈活選擇，但其創建步驟都大同小異。這類產品的創建無法用前面介紹的工廠模式描述，只有建造者模式可以很好地描述該類產品的創建。

模式的定義與特點

建造者（Builder）模式的定義：指將一個復雜對象的構造與它的表示分離，使同樣的構建過程可以創建不同的表示，這樣的設計模式被稱為建造者模式。它是將一個復雜的對象分解為多個簡單的對象，然后一步一步構建而成。它將變與不變相分離，即產品的組成部分是不變的，但每一部分是可以靈活選擇的。

該模式的主要優點如下：

1. 各個具體的建造者相互獨立，有利於系統的擴展。
2. 客戶端不必知道產品內部組成的細節，便於控制細節風險。

其缺點如下：

1. 產品的組成部分必須相同，這限制了其使用范圍。
2. 如果產品的內部變化復雜，該模式會增加很多的建造者類。

建造者（Builder）模式和工廠模式的關注點不同：建造者模式注重零部件的組裝過程，而工廠方法模式更注重零部件的創建過程，但兩者可以結合使用。

模式的結構與實現

建造者（Builder）模式由產品、抽象建造者、具體建造者、指揮者等 4 個要素構成，現在我們來分析其基本結構和實現方法。
1. 模式的結構
建造者（Builder）模式的主要角色如下。

1. 產品角色（Product）：它是包含多個組成部件的復雜對象，由具體建造者來創建其各個滅部件。
2. 抽象建造者（Builder）：它是一個包含創建產品各個子部件的抽象方法的接口，通常還包含一個返回復雜產品的方法 getResult()。
3. 具體建造者(Concrete Builder）：實現 Builder 接口，完成復雜產品的各個部件的具體創建方法。
4. 指揮者（Director）：它調用建造者對象中的部件構造與裝配方法完成復雜對象的創建，在指揮者中不涉及具體產品的信息。

其結構圖如圖 1 所示。

建造者模式的結構圖

圖1 建造者模式的結構圖

模式的應用場景

建造者（Builder）模式創建的是復雜對象，其產品的各個部分經常面臨着劇烈的變化，但將它們組合在一起的算法卻相對穩定，所以它通常在以下場合使用。

• 創建的對象較復雜，由多個部件構成，各部件面臨着復雜的變化，但構件間的建造順序是穩定的。
• 創建復雜對象的算法獨立於該對象的組成部分以及它們的裝配方式，即產品的構建過程和最終的表示是獨立的。

模式的擴展

建造者（Builder）模式在應用過程中可以根據需要改變，如果創建的產品種類只有一種，只需要一個具體建造者，這時可以省略掉抽象建造者，甚至可以省略掉指揮者角色。