.Net工廠方法模式(Factory Method Pattern)
在簡單工廠模式中，我們提到，工廠方法模式是簡單工廠模式的一個延伸，它屬於Gof23中設計模式的建立型設計模式。它解決的仍然是軟體設計中與建立物件有關的問題。它可以更好的處理客戶的需求變化。
引入
我們繼續來說"new"的問題，我們在簡單工廠模式中，將例項化物件的工作推遲到了專門負責建立物件的工廠類中，這樣，在我們事先預知的情況下，可以根據我們的需要動態建立產品類。但是，我們的預知是有限的，客戶的變化可能是無限的。所以，就出現了問題，一旦客戶的變化超越了我們的預知，我們就必須修改我們的原始碼了。這是設計模式所不允許的，怎麼辦呢？工廠方法模式正是解決此類問題的。
問題：具體工廠類的建立工作不能滿足我們的要求了，建立的工作變化了
解決思路：哪裡變化，封裝哪裡。把具體工廠封裝起來。
定義
意圖
定義一個使用者建立物件的介面，讓子類決定例項化哪一個類，工廠方法模式使一個類的例項化延遲到其子類。
參與者
- 抽象產品角色（Product）
定義產品的介面 - 具體產品角色（ConcreteProduct）
實現介面Product的具體產品類 - 抽象工廠角色（Creator）
宣告工廠方法（FactoryMethod），返回一個產品 - 真實的工廠（ConcreteCreator）
實現FactoryMethod工廠方法，由客戶呼叫，返回一個產品的例項
工廠方法模式UML圖
現實生活中的例子
為了方便大家理解，我仍然舉穿衣服方面的一個例子。這個例子與簡單工廠模式中的那個例子有些不同。
據說清朝有個皇帝穿衣非常的奢侈，每種衣服（具體產品類）由一宮女（具體工廠類）專門負責，這樣一來，每增加一種衣服（具體產品類），就要多出一個宮女（具體工廠類），但是他們各負其責，互不影響。皇帝之所以這樣做，是因為針對穿衣服這件事來說，可擴充套件性是非常強的（）。
分析
實現的功能：可以根據皇帝的要求，動態的建立（由宮女去拿）已存在的具體產品（衣服），如果皇帝的要求太苛刻，這種衣服還沒有，只需要增加一個宮女，一個衣服就能夠滿足他的要求了。每個宮女只負責一種衣服（高內聚），要增加一種衣服，對於以前的所有宮女與衣服來說，都不會受到影響（設計模式中所期望的）。說到這裡，是不是明白了工廠方法模式所能解決的問題及其應用了？呵呵。。你一定在想，比簡單工廠模式靈活性高吧。。
抽象工廠角色程式碼
2{
3///<summary>
4///抽象工廠類,定義產品的介面
5///</summary>
6publicinterfaceIFactory
7{
8ICoatCreateCoat();
9}
10}
抽象產品角色程式碼
1namespaceFactoryMethod2{
3///<summary>
4///抽象產品類
5///</summary>
6publicinterfaceICoat
7{
8voidShowCoat();
9}
10}
具體工廠角色程式碼
1namespaceFactoryMethod2{
3///<summary>
4///具體工廠類:用於建立商務上衣類
5///</summary>
6publicclassBusinessFactory:IFactory
7{
8publicICoatCreateCoat()
9{
10returnnewBusinessCoat();
11}
12}
13
14///<summary>
15///具體工廠類,用於建立時尚上衣
16///</summary>
17publicclassFashionFactory:IFactory
18{
19publicICoatCreateCoat()
20{
21returnnewFashionCoat();
22}
23}
24}
具體產品角色程式碼
1namespaceFactoryMethod2{
3///<summary>
4///具體產品類,商務上衣類
5///</summary>
6publicclassBusinessCoat:ICoat
7{
8publicvoidShowCoat()
9{
10Console.WriteLine("這件是商務上衣");
11}
12}
13
14///<summary>
15///具體產品類,時尚上衣類
16///</summary>
17publicclassFashionCoat:ICoat
18{
19publicvoidShowCoat()
20{
21Console.WriteLine("這件是時尚上衣");
22}
23}
24}
25
客戶端程式碼
1namespaceFactoryMethod2{
3///<summary>
4///客戶端程式碼
5///</summary>
6classClient
7{
8staticvoidMain(string[]args)
9{
10//為了方便以後修改,將工廠類的類名寫在應用程式配置檔案中
11stringfactoryName=ConfigurationManager.AppSettings["FactoryName"];
12
13IFactoryfactory=(IFactory)Assembly.Load("ConcreteFactory").CreateInstance("FactoryMethod."+factoryName);
14
15ICoatcoat=factory.CreateCoat();
16//顯示你要的上衣
17coat.ShowCoat();
18}
19}
20}
客戶端程式碼需要注意的兩個地方：
1，把具體工廠類類名稱寫在了應用程式配置檔案中，方便修改
2，用到了反射，利用.NET提供的反射可以根據類名來建立它的例項，非常方便
由反射想到的：
下面這一段內容不是計劃要寫的。
如果在具體工廠中，每次new的物件都是一個，而且這些類是繼承自抽象產品介面的，那麼我們用簡單工廠模式也可以實現動態的增加具體產品類。這樣來做，在簡單工廠模式中最核心的部分----工廠類不要根據傳來的條件去動態建立產品類，利用反射機制去建立。把要例項化的類名放在應用程式配置檔案中，呵呵。。這樣利用.NET特有的反射就可以用簡單工廠模式解決更多的問題了，工廠方法模式的一部分問題也是可以通過“這樣的簡單工廠模式”解決的，在需要增加具體產品類時，不用增加具體工廠，是不是簡單一些呀。下去試一下。。。
優點：
- 基於工廠角色和產品角色的多型性設計是工廠方法模式的關鍵。它能夠使工廠可以自主確定建立何種產品物件。而且如何建立一個具體產品的細節完全封裝在具體工廠內部，符合高內聚，低耦合。
- 在系統中加入新產品時，無需修改抽象工廠和抽象產品提供的介面，無需修改客戶端，也無需修改其他的具體工廠和具體產品，很好的利用了封裝和委託。
缺點：
- 在新增新產品時，需要編寫新的具體產品類（其實這不算一個缺點，因為這是不可避免的），要增加與之對應的具體工廠類。
應用情景：
- 類不知道自己要建立哪一個物件時
- 類用它的子類來指定建立哪個物件
- 當類將建立物件的職責委託給多個幫助子類中的某一個，並且你希望將哪一個幫助子類是代理者這一資訊區域性化的時候
工廠方法模式在ASP.NET HTTP通道中的應用，TerryLee在他的那篇檔案中寫的非常好，推薦去看一下。
轉載自：http://www.cnblogs.com/anlyren/archive/2008/01/26/factory_method.html