建立型模式總結

建立型模式列表

abstract factory

creates an instance of several families of classes

builder

separates object construction from its representation

factory method

creates an instance of several derived classes

prototype

a fully initialized instance to be copied or cloned

singleton

a class of which only a single instance can exist

建立型模式，就是用來建立物件的模式，抽象了例項化的過程。它幫助乙個系**立於如何建立、組合和表示它的那些物件。本文主要對前面幾章五種常用建立型模式進行了比較，通過乙個遊戲開發場景的例子來說該如何使用建立型模式。

一、為什麼需要建立型模式

所有的建立型模式都有兩個永恆的主旋律：第一，它們都將系統使用哪些具體類的資訊封裝起來；第二，它們隱藏了這些類的例項是如何被建立和組織的。外界對於這些物件只知道它們共同的介面，而不清楚其具體的實現細節。正因如此，建立型模式在建立什麼（what），由誰（who）來建立，以及何時（when）建立這些方面，都為軟體設計者提供了盡可能大的靈活性。

假定在乙個遊戲開發場景中，會用到乙個現代風格房屋的物件，按照我們的一般想法，既然需要物件就建立乙個：

modernroom room = new modernroom();

好了，現在現代風格房屋的物件已經有了，如果這時房屋的風格變化了，需要的是古典風格的房屋，修改一下：

classicalroom room = new classicalroom();

試想一下，在我們的程式中有多少處地方用到了這樣的建立邏輯，而這裡僅僅是房屋的風格變化了，就需要修改程式中所有的這樣的語句。現在我們封裝物件建立的邏輯，把物件的建立放在乙個工廠方法中：

modernfactory factory = new modernfactory();

modernroom room = factory.create();

當房屋的風格變化時，只需要修改

classicalfactory factory = new classicalfactory();

classicalroom room = factory.create();

而其它的用到room的地方仍然不變。這就是為什麼需要建立型模式了。建立者模式作用可以概括為如下兩點：

1．封裝建立邏輯，絕不僅僅是new乙個物件那麼簡單。

2．封裝建立邏輯變化，客戶**盡量不修改，或盡量少修改。

二、常見的五種建立型模式

單件模式（singleton pattern）解決的是實體物件的個數問題，其他的都是解決new所帶來的耦合關係問題。

工廠方法模式（factory pattern）在工廠方法中，工廠類成為了抽象類，其實際的建立工作將由其具體子類來完成。工廠方法的用意是定義乙個建立產品物件的工廠介面，將實際建立工作推遲到子類中去，強調的是「單個物件」的變化。

抽象工廠模式（abstract factory）抽象工廠是所有工廠模式中最為抽象和最具有一般性的一種形態。抽象工廠可以向客戶提供乙個介面，使得客戶可以在不必指定產品的具體型別的情況下，建立多個產品族中的產品物件，強調的是「系列物件」的變化。

生成器模式（builder pattern）把構造物件例項的邏輯移到了類的外部，在這個類的外部定義了這個類的構造邏輯。他把乙個複雜物件的構造過程從物件的表示中分離出來。其直接效果是將乙個複雜的物件簡化為乙個比較簡單的目標物件。他強調的是產品的構造過程。

原型模式（prototype pattern）和工廠模式一樣，同樣對客戶隱藏了物件建立工作，但是，與通過對乙個類進行例項化來構造新物件不同的是，原型模式是通過拷貝乙個現有物件生成新物件的。

三、如何選擇使用建立型模式

繼續考慮上面提到的遊戲開發場景，假定在這個遊戲場景中我們使用到的有牆（wall），屋子（room），門（door）幾個部件。在這個過程中，同樣是物件的建立問題，但是會根據所要解決的問題不同而使用不同的建立型模式。

如果在遊戲中，乙個屋子只允許有乙個門存在，那麼這就是乙個使用signleton模式的例子，確保只有乙個door類的例項被建立。解決的是物件建立個數的問題。

示例**：

在遊戲中需要建立牆，屋子的例項時，為了避免直接對構造器的呼叫而例項化類，這時就是工廠方法模式了，每乙個部件都有它自己的工廠類。解決的是「單個物件」的需求變化問題。

示例**：

在遊戲場景中，不可能只有一種牆或屋子，有可能有現代風格（modern），古典風格（classical）等多系列風格的部件。這時就是一系列物件的建立問題了，是乙個抽象工廠的例子。解決的是「系列物件」的需求變化問題。

示例**：

如果在遊戲場景中，構成某乙個場景的演算法比較穩定，例如：這個場景就是用四堵牆，乙個屋子，一扇門來構成的，但具體是用什麼風格的牆、屋子和門則是不停的變化的，這就是乙個生成器模式的例子。解決的是「物件部分」的需求變化問題。

示例**：

如果在遊戲中，需要大量的古典風格或現代風格的牆或屋子，這時可以通過拷貝乙個已有的原型物件來生成新物件，就是乙個原型模式的例子了。通過轉殖來解決「易變物件」的建立問題。

示例**：

究竟選用哪一種模式最好取決於很多的因素。使用abstract factory、prototype pattern或builder pattern的設計比使用factory method的設計更加靈活，但是也更加複雜，尤其abstract factory需要龐大的工廠類來支援。通常，設計以使用factory method開始，並且當設計者發現需要更大的靈活性時，設計便會向其他設計模式演化，當你在多個設計模式之間進行權衡的時候，了解多個設計模式可以給你提供更多的選擇餘地。

1、建立型模式專題總結：http://hi.baidu.com/nana****ou/blog/item/42d96fcf29aa913bf9dc6133.html

2、建立型模式：http://blog.163.com/jinsir@yeah/blog/static/105444059200902112958170/

3、建立型模式之間的比較：http://blog.donews.com/godwood/archive/2006/01/18/699647.aspx

建立型模式總結

建立型模式總結

建立型模式總結

建立型模式總結

相關推薦