建立型設計模式小結

建立型模式，就是用來建立對象的模式，它抽象了對象的建立過程。本系列文章介紹了Gof設計模式中的5種建立型模式，另外對簡單工廠模式也進行了介紹，下面通過一個表格來說明它們之間的關系。

概述

　　建立型模式，就是用來建立對象的模式，它抽象了對象的建立過程。本系列文章介紹了Gof設計模式中的5種建立型模式，另外對簡單工廠模式也進行了介紹，下面通過一個表格來說明它們之間的關系。

名稱	GoF的定義	功能描述
Singleton	保證一個類僅有一個執行個體，并提供一個該執行個體的全局通路點。	解決的是類執行個體化個數的問題，嚴格控制實體對象的數量
Simple Factory	非23種Gof模式，沒有Gof定義(個人定義：專門定義一個類來負責建立其他類的執行個體，被建立的執行個體常常具有共同的父類。)	解決的是“某個對象”的建立工作，由于需求的變化，這個對象的具體實作常常面臨着劇烈的變化，但是這個對象擁有的接口相對穩定。簡單工廠實作了用戶端和對象建立的解耦。
Factory Method	定義建立對象的接口，讓子類決定執行個體化哪一個類。工廠方法使得一個類的執行個體化延遲到其子類。	功能和簡單工廠一樣，它具有簡單工廠的優點，并規避了簡單工廠的缺點(違反“開放-關閉原則”)
Abstract Factory	提供一個建立一系列相關或互相依賴對象的接口，而無需指定它們具體的類。	抽象工廠解決了一個系列易變對象的建立問題
Builder	将一個複雜對象的建構與它的表現分離，使得同樣的建構過程可以建立不同的表現	應對項目中一些複雜對象的建立工作。所謂“複雜對象”，是指對象中還含有其它的子對象。
Prototype	使用原型執行個體指定建立對象的種類，并通過複制這個原型建立新的對象	解決了某些結構複雜的對象的建立工作。由于需求的變化，這些對象經常面臨着劇烈的變化，但是它們卻擁有比較穩定一緻的接口，原型模式通過原型(可以了解為一個特殊的工廠類)來克隆易變對象

為什麼需要建立型模式

　　所有的建立型模式都有兩個永恒的主題：第一，它們都将系統使用哪些具體類的資訊封裝起來；第二，它們隐藏了這些類的執行個體是如何被建立群組織的。外界對于這些對象隻知道它們共同的接口，而不清楚其具體的實作細節。正因如此，建立型模式在建立什麼(what)、由誰(who)建立、以及何時(when)建立這些方面，都為軟體設計者提供了盡可能大的靈活性。下面通過應用場景來說明。

　　假設現在要開發一個遊戲，遊戲中會用到一個現代風格房屋的對象，我們一般會使用如下代碼來建立：

ModernRoom room = [[ModernRoom alloc] init];      

　　這樣一個現代風格的房屋對象就建立好了。但現在由于客戶需求的變化，客戶方要求建立一個古典風格的房屋，那麼我們就需要将上面的代碼修改為：

ClassicalRoom room = [[ClassicalRoom alloc] init];      

　　從代碼看也沒什麼問題，但大家可以試想一下：在我們的程式中可能有很多地方使用了這樣風格的建立代碼，這裡僅僅是假設房屋的風格變化，就需要修改程式中所有的房屋風格建立代碼，那麼其他的話，大家可以想象一下修改的工作量。現在有了建立型模式，我們對對象建立過程采用工廠方法模式封裝，把對象的建立放在一個工廠方法中，用戶端調用的代碼可能如下：

// 這個地方的@" ModernRoomFactory "可以寫到配置檔案中
id<Factory> factory = [[[NSClassFromString(@"ModernRoomFactory") alloc] init] autorelease];
id<IRoom> chart = [factory createRoom];
// 其他操作......      

　　當房屋的風格變化時，我們隻需要修改配置檔案中@" ModernRoomFactory "，代碼不做任何改動就可以了。這就是我們為什麼需要建立型模式。建立者模式作用可以概括為如下兩點：

• 封裝建立邏輯，絕不僅僅是alloc一個對象那麼簡單。
• 封裝建立邏輯變化，客戶代碼盡量不修改，或盡量少修改。

如何使用建立型模式

　　我們繼續上面的遊戲開發場景：假定在遊戲中我們需要用到牆(Wall)、屋子(Room)、門(Door)等部件。同樣是對象的建立問題，但是會根據所要解決的問題不同而使用不同的建立型模式。

　　假定一個屋子隻允許有一個門存在，那麼這就是一個使用Signleton模式的例子，確定隻有一個Door類的執行個體被建立，解決的是對象建立個數的問題。

　　在遊戲中需要建立牆、屋子的執行個體時，為了避免直接對構造器的調用而執行個體化類，也是應對這些類可能有不同表現的問題，這時我們會使用簡單工廠模式或工廠方法模式，每一個部件都有它自己的工廠類，解決的是“單個對象”的需求變化問題。

　　更進一步，在遊戲場景中，不可能隻有一種風格的牆或屋子，可能有現代風格的(Modern)、古典風格(Classical)等其他系列風格的部件。這時就是一系列對象的建立問題了，可以使用抽象工廠模式，解決的是“系列對象”的需求變化問題。

　　現在再考慮一下：我們知道一個屋子一般由4面牆、一扇窗戶、一張門、一個天花闆構成，但具體用什麼風格的牆、窗戶、門、天花闆是不斷變化的，這時我們可以用生成器模式，解決的是“對象部分”的需求變化問題。

　　如果在遊戲中，需要大量的古典風格或現代風格的牆或屋子，這時我們可以通過拷貝一個已有的原型對象來生成新對象，這就是原型模式。通過克隆來解決“易變對象”的建立問題。

　　究竟選用哪一種模式，取決于很多的因素。使用Abstract Factory、Prototype或Builder的設計比使用Factory Method的設計更加靈活，但是也更加複雜，尤其Abstract Factory需要龐大的工廠類來支援。通常，設計以使用Factory Method開始，當需要更大的靈活性時，設計便會向其他設計模式演化，了解多個設計模式，可以讓你有更多的選擇餘地。

　　傳回目錄

循自然之道，撫浮躁之心