文章很長很精彩,如是初學請耐心觀看。(大神請繞道!)
簡單工廠模式:
1.創建型模式
2.簡單工廠模式概述
3.簡單工廠模式的結構與實現
4.簡單工廠模式的應用實例
5.創建對象與使用對象
6.簡單工廠模式的簡化
7.簡單工廠模式的優缺點與適用環境
1.創建型模式(Creational Pattern):
關注對象的創建過程 創建型模式對類的實例化過程進行了抽象,能夠將軟件模塊中對象的創建和對象的使用分離,對用戶隱藏了類的實例的創建細節 創建型模式描述如何將對象的創建和使用分離,讓用戶在使用對象時無須關心對象的創建細節,從而降低系統的耦合度,讓設計方案更易於修改和擴展. (創建型模式的關注點:1.創建什麼? 2.由誰創建? 3.何時創建?)
模式名稱 定義 學習難度 使用頻率
簡單工廠模式
(Simple Factory Pattern)
定義一個工廠類,它可以根據參數的不同返回不同類的實例,被創建的實例通常都具有共同的父類。 ★★☆☆☆ ★★★☆☆工廠方法模式
(Factory Method Pattern)
定義一個用於創建對象的接口,但是讓子類決定將哪一個類實例化。工廠方法模式讓一個類的實例化延遲到其子類。 ★★☆☆☆ ★★★★★抽象工廠模式
(Abstract Factory Pattern)
提供一個創建一系列相關或相互依賴對象的接口,而無須指定它們具體的類。 ★★★★☆ ★★★★★建造者模式
(Builder Pattern)
將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示。 ★★★★☆ ★★☆☆☆原型模式
(Prototype Pattern)
使用原型實例指定待創建對象的類型,並且通過復制這個原型來創建新的對象。 ★★★☆☆ ★★★☆☆單例模式
(Singleton Pattern)
確保一個類只有一個實例,並提供一個全局訪問點來訪問這個唯一實例。 ★☆☆☆☆ ★★★★☆2.簡單工廠模式概述:
簡單工廠模式基本實現流程
具體產品類:將需要創建的各種不同產品對象的相關代碼封裝到具體產品類中
抽象產品類:將具體產品類公共的代碼進行抽象和提取後封裝在一個抽象產品類中
工廠類:提供一個工廠類用於創建各種產品,在工廠類中提供一個創建產品的工廠方法,該方法可以根據所傳入參數的不同創建不同的具體產品對象
客戶端:只需調用工廠類的工廠方法並傳入相應的參數即可得到一個產品對象
1 if(arg.Equals("A")) 2 { 3 return new ConcreteProductA(); 4 } 5 else if(arg.Equals("B")) 6 { 7 return new ConcreteProductB(); 8 } 9 else 10 { 11 ....... 12 }
簡單工廠模式的定義:
(1)單工廠模式 (Simple Factory Pattern):定義一個工廠類,它可以根據參數的不同返回不同類的實例,被創建的實例通常都具有共同的父類。
(2)工廠模式中用於創建實例的方法通常是靜態(static)方法,因此又被稱為靜態工廠方法(Static Factory Method)模式
要點:如果需要什麼,只需要傳入一個正確的參數,就可以獲取所需要的對象,而無須知道其創建細節
★簡單工廠模式的結構
3.簡單工廠模式的結構與實現
簡單工廠模式的結構
簡單工廠模式包含以下3個角色:
Factory(工廠角色)
Product(抽象產品角色)
ConcreteProduct(具體產品角色)
簡單工廠模式的實現
典型的抽象產品類代碼:
1 abstract class Product 2 { 3 //所有產品類的公共業務方法 4 public void MethodSame() 5 { 6 //公共方法的實現 7 } 8 9 //聲明抽象業務方法 10 public abstract void MethodDiff(); 11 }
典型的具體產品類代碼:
1 class ConcreteProductA : Product 2 { 3 //實現業務方法 4 public override void MethodDiff() 5 { 6 //業務方法的實現 7 } 8 }
典型的工廠類代碼:
class Factory { //靜態工廠方法 public static Product GetProduct(string arg) { Product product = null; if (arg.Equals("A")) { product = new ConcreteProductA(); //初始化設置product } else if (arg.Equals("B")) { product = new ConcreteProductB(); //初始化設置product } return product; } }
典型的客戶端代碼:
1 class Program 2 { 3 static void Main(string[] args) 4 { 5 Product product; 6 product = Factory.GetProduct("A"); //通過工廠類創建產品對象 7 product.MethodSame(); 8 product.MethodDiff(); 9 } 10 }
4.簡單工廠模式的應用實例
實例說明:
某軟件公司要基於C#語言開發一套圖表庫,該圖表庫可以為應用系統提供多種不同外觀的圖表,例如柱狀圖(HistogramChart)、餅狀圖(PieChart)、折線圖(LineChart)等。該軟件公司圖表庫設計人員希望為應用系統開發人員提供一套靈活易用的圖表庫,通過設置不同的參數即可得到不同類型的圖表,而且可以較為方便地對圖表庫進行擴展,以便能夠在將來增加一些新類型的圖表。
現使用簡單工廠模式來設計該圖表庫。
實例代碼
(1) Chart:抽象圖表接口,充當抽象產品類
(2) HistogramChart:柱狀圖類,充當具體產品類
(3) PieChart:餅狀圖類,充當具體產品類
(4) LineChart:折線圖類,充當具體產品類
(5) ChartFactory:圖表工廠類,充當工廠類
(6) Program:客戶端測試類
參考代碼: (DesignPatterm\SimpleFactory)
引入配置文件:App.config:
using System.Configuration; …… //讀取配置文件 string chartStr = ConfigurationManager.AppSettings["chartType"]; …… <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="chartType" value="histogram"/> </appSettings> </configuration> …… Chart chart; chart = ChartFactory.GetChart(chartStr); //通過靜態工廠方法創建產品 ……
5.創建與使用對象
C#語言創建對象的幾種方式
使用new關鍵字直接創建對象
通過反射機制創建對象
通過克隆方法創建對象
通過工廠類創建對象
使用new關鍵字創建對象:
class Login { private UserDAO udao; public Login() { udao = new OracleUserDAO(); //創建對象 //上面的這行代碼 若改為SQL ServerUserDAO必須修改源代碼, //違背開閉原則 } public void Execute() { //其他代碼 udao.FindUserById(); //使用對象 //其他代碼 } }
實例分析
引入工廠類UserDAOFactory:
實例分析
引入工廠類UserDAOFactory
如果UserDAO的某個子類的構造函數發生改變或者需要添加或移除不同的子類,只要維護UserDAOFactory的代碼,不會影響到Login
如果UserDAO的接口發生改變,例如添加、移除方法或改變方法名,只需要修改Login,不會給UserDAOFactory帶來任何影響
將對象的創建與使用分離的其他好處
防止用來實例化一個類的數據和代碼在多個類中到處都是,可以將有關創建的知識搬移到一個工廠類中,解決代碼重復、創建蔓延的問題
構造函數的名字都與類名相同,從構造函數和參數列表中大家很難了解不同構造函數所構造的產品的差異 將對象的創建過程封裝在工廠類中,可以提供一系列名字完全不同的工廠方法,每一個工廠方法對應一個構造函數,客戶端可以以一種更加可讀、易懂的方式來創建對象
何時不需要工廠?
無須為系統中的每一個類都配備一個工廠類
如果一個類很簡單,而且不存在太多變化,其構造過程也很簡單,此時就無須為其提供工廠類,直接在使用之前實例化即可
否則會導致工廠泛濫,增加系統的復雜度
例如:string類
何時不需要工廠?
無須為系統中的每一個類都配備一個工廠類
如果一個類很簡單,而且不存在太多變化,其構造過程也很簡單,此時就無須為其提供工廠類,直接在使用之前實例化即可
否則會導致工廠泛濫,增加系統的復雜度
例如:string類
6.簡單工廠模式的簡化
將抽象產品類和工廠類合並,將靜態工廠方法移至抽象產品類中
7.簡單工廠模式的優缺點與適用環境
模式優點:
實現了對象創建和使用的分離
客戶端無須知道所創建的具體產品類的類名,只需要知道具體產品類所對應的參數即可
通過引入配置文件,可以在不修改任何客戶端代碼的情況下更換和增加新的具體產品類,在一定程度上提高了系統的靈活性
模式缺點:
工廠類集中了所有產品的創建邏輯,職責過重,一旦不能正常工作,整個系統都要受到影響
增加系統中類的個數(引入了新的工廠類),增加了系統的復雜度和理解難度
系統擴展困難,一旦添加新產品不得不修改工廠邏輯
由於使用了靜態工廠方法,造成工廠角色無法形成基於繼承的等級結構,工廠類不能得到很好地擴展
模式適用環境:
工廠類負責創建的對象比較少,由於創建的對象較少,不會造成工廠方法中的業務邏輯太過復雜
客戶端只知道傳入工廠類的參數,對於如何創建對象並不關心
到這裡,我的文章已近尾聲。感謝觀看我的Blog, 後續還會有更精彩的內容,請加關注點贊,謝謝!