幾點說明html
三種工廠的說明設計模式
簡單工廠(SimpleFactory):定義一個類來負責建立其餘類的實例,被建立的實例一般都具備共同的父類或接口。app
工廠方法(FactoryMethod):定義一個用於建立對象的接口,讓子類決定實例化哪個類,使一個類的實例化延遲到了子類。設計
抽象工廠(AbstractFactory):提供一個建立一系列相關或相互依賴對象的接口,而無須指定它們的具體類。code
三種工廠的實現htm
注意:Singleton.SingletonOperateClass_1/2/3/4/5/6 是使用以前寫的一個關於單例模式的筆記時建立的。對象
簡單工廠的實現思路:在工廠類中,使用一個以「產品基類」做爲返回值類型的方法,用於生產。這個方法須要有一個參數,用於表述須要建立的是哪種「產品子類」。而後再在這個方法中進行判斷,以返回相應的對象。blog
簡單工廠的好處:經過使用工廠方法來建立對象,能夠有效的解決在建立對象時耦合性太高的問題。若是我在客戶類中,直接使用New來實例化產品類,那麼,若是當我想使用另外一種更好的類來替代以前的類的時候,我就得每個客戶類中都去修改。而使用工廠方法,就能夠作到只修改這一個方法,從而實現低耦合性。固然,簡單工廠的一個很致命的缺點,就是必需要知道傳入什麼以及會傳出什麼。這樣對於類的擴展不是十分的方便。接口
「簡單工廠 - Simple Factory」
public static Singleton.OperateBase getSingletonOperateClass(int selected) { switch (selected) { case 1: return Singleton.SingletonOperateClass_1.Operate; case 2: return Singleton.SingletonOperateClass_2.Single; case 3: return Singleton.SingletonOperateClass_3.Operate; case 4: return Singleton.SingletonOperateClass_4.Operate; case 5: return Singleton.SingletonOperateClass_5.Operate; case 6: return Singleton.SingletonOperateClass_6.Operate; default: return null; } }
工廠方法的實現思路:若是說,簡單工廠是使用傳入的參數來控制生成什麼樣的子類來返回,從而在解決耦合性問題的同時,也帶來了不夠靈活的問題。那麼工廠方法就是使用多個相應對象的工廠來返回實例化後的子類,而不是經過傳入參數來控制。ip
這裏根據一篇參考的文章中提出的方法,可使用反射來解決工廠方法中,要使用哪一種子類,以及解決簡單工廠中的傳入參數的問題。我的以爲十分的好!具體的實現方法,就是寫一個XML配置文件,或者乾脆寫在app.config中,而後來讀取相應的節點,從而獲取到有關的參數信息。
「工廠方法 - Factory Method」
/// <summary> /// Factory Mathod Interface /// </summary> public interface IFactory_A { Singleton.OperateBase getSingletonOperateClass(); } /// <summary> /// Factory Method 1 /// </summary> public sealed class OperateFactory_1: IFactory_A { public Singleton.OperateBase getSingletonOperateClass() { return Singleton.SingletonOperateClass_1.Operate; } } /// <summary> /// Factory Method 2 /// </summary> public class OperateFactory_2: IFactory_A { public Singleton.OperateBase getSingletonOperateClass() { return Singleton.SingletonOperateClass_2.Single; } }
抽象工廠的實現思路:若是說簡單工廠與工廠方法是對同一個問題的兩種不一樣的解決方法的話,抽象工廠就是解決一系列這種問題的方法。由於其主要的做用就是生產一系列相互依賴的對象,而不用去關心它們具體的實現。
固然,抽象工廠相對於前兩種方法來講,也是有一點複雜的。而也正是從這種方法開始,使用設計模式就須要一個好的「設計」了,否則會很驚訝的發現,越用設計模式,所產生的問題越多、系統越複雜、可控性越差。
這個模式的實現相對來講,仍是比較直觀的。首先要有一個總的工廠接口或者抽象類(建議使用接口),這個接口就是在客戶類中,要實例化的那個模板。而後要有這個接口的多種不一樣的工廠實現類。具體有多少個實現類,這個要看你的系統須要而定。這些實現類都是用於實例化一系統的產品對象。也就是說,咱們還要有一系列的產品對象用於實例化。咱們首先要有這一系列產品對象的抽象類,而後再針對每個系列建立相應的子類,固然,子類的數量以及內容仍是要看你具體的須要了。
「抽象工廠 - Abstract Factory」
public interface IFactory_A { ProductBass_1 getProduct_1(); ProductBass_2 getProduct_2(); } public sealed class OperateFactory_1: IFactory_A { public static ProductBass_1 getProduct_1() { return new ProductClass_1_1(); } public static ProductBass_2 getProduct_2() { return new ProductClass_2_1(); } } public class OperateFactory_2: IFactory_A { public ProductBass_1 getProduct_1() { return new ProductClass_1_2(); } public ProductBass_2 getProduct_2() { return new PorductClass_2_2(); } } /// <summary> /// Description of ProductBass_1. /// </summary> public abstract class ProductBass_1 {} public class ProductClass_1_1: ProductBase_1 { public ProductClass_1_1() {} } public class ProductClass_1_2: ProductBase_1 { public ProductClass_1_2() {} } public abstract class ProductBass_2 {} public class ProductClass_2_1: ProductBase_2 { public ProductClass_2_1() {} } public class ProductClass_2_2: ProductBase_2 { public ProductClass_2_2() {} }
三種工廠的區別
相比較而言,簡單工廠在實現上是最簡單的,工廠方法在實現上,較簡單工廠更復雜一點,但在靈活性上,更好一些。而抽象工廠方法是這三種方法中,最複雜的一種,固然,其與以前兩種要解決的問題也有必定的區別。
咱們能夠認爲,抽象工廠的實現是依託於以前兩種方法的。咱們也能夠認爲,抽象工廠是對以前兩種方法在建立一系列對象上不足的一個有效補充。
若是說,在設計上作到極致,或總體項目比較小的話,在簡單工廠與工廠方法中,我的比較傾向於簡單工廠這種方式。由於其不用包含太多的子類。
有文章指出,簡單工廠在內聚方面不夠充分。這在OOP方面,確實是簡單工廠的一個感傷。可是若是咱們的換種思路去考慮的話,將工廠類看作是一個靜態不變對象,其也是一個高內聚的實現,由於其只有一個做用,就是生產……固然,這是有點阿Q了……
參考