.Net創(chuàng)建型設計模式之抽象工廠模式(Abstract?Factory)
一、動機(Motivation)
在軟件系統(tǒng)中,經(jīng)常面臨著“一系列相互依賴的對象”的創(chuàng)建工作;同時,由于需求的變化,往往存在更多系列對象的創(chuàng)建工作。
如何應對這種變化?如何繞過常規(guī)的對象創(chuàng)建方法(new),提供一種“封裝機制”來避免客戶程序和這種“多系列具體對象創(chuàng)建工作”的緊耦合?
二、意圖(Intent)
提供一個接口,讓該接口負責創(chuàng)建一系列“相關或者相互依賴的對象”,無需指定它們具體的類。
三、結構(Structure)
ProductA1和ProductB1是一個系列,ProductA2和ProductB2是另一個系列。ConcreteFactory1是創(chuàng)建系列1的工廠方法,ConcreteFactory2是創(chuàng)建系列2的工廠方法??蛻舫绦駽lient只依賴了AbstractFactory和AbstractProductA、AbstractProductB,也就是客戶程序不依賴于具體實現(xiàn),而是只依賴與抽象類。
如果現(xiàn)在需要創(chuàng)建一個系列3運用到客戶程序,我們只需要再寫一個系列3的工廠,繼承自AbstractFactory,這個工廠提供了2個實現(xiàn):
CreateProductA();
CreateProductB();
它們分別返回ProductA3(繼承自AbstractProductA)、ProductB3(繼承自AbstractProductB)。
也就是說,如果新增了系列3,Client程序可以完全不用改動,可能只需要改一些配置文件,增加一些新dll就可以應對變化。
四、模式的組成
可以看出,在抽象工廠模式的結構圖有以下角色:
(1)、抽象產(chǎn)品類角色(AbstractProduct):為抽象工廠中相互依賴的每種產(chǎn)品定義抽象接口對象,也可以這樣說,有幾種產(chǎn)品,就要聲明幾個抽象角色,每一個抽象產(chǎn)品角色和一種具體的產(chǎn)品相匹配。
(2)、具體產(chǎn)品類(ConcreteProduct):具體產(chǎn)品類實現(xiàn)了抽象產(chǎn)品類,是針對某個具體產(chǎn)品的實現(xiàn)的類型。
(3)、抽象工廠類角色(Abstract Factory):定義了創(chuàng)建一組相互依賴的產(chǎn)品對象的接口操作,每種操作和每種產(chǎn)品一一對應。
(4)、具體工廠類角色(ConcreteFactory):實現(xiàn)抽象類里面的所有抽象接口操作,可以創(chuàng)建某系列具體的產(chǎn)品,這些具體的產(chǎn)品是“抽象產(chǎn)品類角色”的子類。
五、抽象工廠的具體代碼實現(xiàn)
作為長子的我,希望能有一套歐式風格的房子,再加上田園風光,此生足矣。我弟弟就不一樣了,他想要一套現(xiàn)代樣式的房子,如果兄弟姊妹再多年一點,那就有更多的要求了。由于房子由房頂、地板、窗戶和房門組成,其他組件暫時省略,有這么多套房子要建設,每套房子的房頂、地板、窗戶和房門都是一個體系的,那就讓我們看看如何使用【抽象工廠】模式來實現(xiàn)不同房屋的建造。
//抽象道路 public abstract class Road { } //抽象房屋 public abstract class Building { } //現(xiàn)代風格道路 public class ModernRoad : Road { } //現(xiàn)代風格房屋 public class ModernBuilding : Building { } //古典風格道路 public class ClassicRoad : Road { } //古典風格房屋 public class ClassicBuilding : Building { } //抽象工廠 public abstract class FacilitiesFactory { public abstract Road CreateRoad(); public abstract Building CreateBuilding(); } //現(xiàn)代風格 public class ModernFacilitiesFactory : FacilitiesFactory { public override Road CreateRoad() { return new ModernRoad(); } public override Building CreateBuilding() { return new ModernBuilding(); } } //古典風格 public class ClassicFacilitiesFactory : FacilitiesFactory { public override Road CreateRoad() { return new ClassicRoad(); } public override Building CreateBuilding() { return new ClassicBuilding(); } }
客戶程序:
可以看出,客戶程序依賴的全部是抽象類,在客戶程序代碼中沒有出現(xiàn)過任何具體的實現(xiàn)類。因為在系列需要變化的時候,是不需要改變抽象類的,只是增加一個抽象類的實現(xiàn)而已,又由于客戶程序只依賴于抽象,所以系列變化的時候客戶程序完全無需變化。
internal class GameManager { private FacilitiesFactory facilitiesFactory; private Road road; private Building building; public GameManager(FacilitiesFactory facilitiesFactory) { this.facilitiesFactory = facilitiesFactory; } public void BuildGameFacilities() { road = facilitiesFactory.CreateRoad(); building = facilitiesFactory.CreateBuilding(); } public void Run() { Console.WriteLine(road); Console.WriteLine(building); } }
應用到具體程序(現(xiàn)代風格):
可以看出,風格由Modern改變?yōu)镃lassic的時候,我們封裝好的GameManager客戶程序沒有改變,這就是我們想要的結果。GameManager的邏輯非常復雜,現(xiàn)在它的穩(wěn)定,能夠大大方便我們的工作。
GameManager g = new GameManager(new ModernFacilitiesFactory()); g.BuildGameFacilities(); g.Run();
改造
第一種改造
就是在系列對象不發(fā)生系列添加的情況下,使用配置文件來進行例子中場景風格的替換。添加一個App.config文件,在其中加入風格設置的字段。
<?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="factoryName" value="ModernFacilitiesFactory"></add> </appSettings> </configuration>
然后,在代碼中讀取這個配置字段,根據(jù)配置字段的值來做實現(xiàn)。首先實現(xiàn)一個構建方法,然后再在客戶程序中調(diào)用。
public static FacilitiesFactory GetInstance() { string factoryName = ConfigurationSettings.AppSettings["factoryName"]; FacilitiesFactory f; switch (factoryName) { case "ModernFacilitiesFactory": f = new ModernFacilitiesFactory(); break; case "ClassicFacilitiesFactory": f = new ClassicFacilitiesFactory(); break; default: f = null; break; } return f; } //客戶程序 public static void Main() { GameManager g = new GameManager(GetInstance()); g.BuildGameFacilities(); g.Run(); }
第二種改造
其實還有一種需求就是擴展新的系列對象,如果還是不需要對客戶程序進行維護,而僅是添加了新的系列對象的類,那將是很舒服的一件事。這樣我們就可以通過添加DLL并配合配置文件的使用,就能在不修改源程序代碼的情況下,擴展出我們需要的新的系列對象
public staticFacilitiesFactory GetInstance() { string factoryName = ConfigurationSettings.AppSettings["factoryName"]; FacilitiesFactory f; if (factoryName != "") f = (FacilitiesFactory)Assembly.Load(factoryName).CreateInstance(factoryName); else f = null; return f; }
這樣,我們在擴展時僅需將擴展的DLL放在相應的路徑下并配合配置文件即實現(xiàn)了我們的擴展。
六、抽象工廠的實現(xiàn)要點
- 如果沒有應對“多系列對象創(chuàng)建”的需求變化,則沒有必要使用AbstractFactory模式,這時候使用簡單的靜態(tài)工廠完全可以。
- “系列對象"指的是這些對象之間有相互依賴、或作用的關系,例如游戲開發(fā)場景中“道路”與“房屋”的依賴,“道路”與“地道”的依賴。
- AbstractFactory模式主要在于應對“新系列”的需求變動。其缺點在于難以應對“新對象”的需求變動。
- AbstractFactory模式經(jīng)常和FactoryMethod模式共同組合來應對“對象創(chuàng)建”的需求變化。
抽象工廠模式的優(yōu)點:
【抽象工廠】模式將系列產(chǎn)品的創(chuàng)建工作延遲到具體工廠的子類中,我們聲明工廠類變量的時候是使用的抽象類型,同理,我們使用產(chǎn)品類型也是抽象類型,這樣做就盡可能的可以減少客戶端代碼與具體產(chǎn)品類之間的依賴,從而降低了系統(tǒng)的耦合度。耦合度降低了,對于后期的維護和擴展就更有利,這也就是【抽象工廠】模式的優(yōu)點所在。可能有人會說在Main方法里面(這里的代碼就是客戶端的使用方)還是會使用具體的工廠類,對的。這個其實我們通過Net的配置,把這部分移出去,最后把依賴關系放到配置文件中。如果有新的需求我們只需要修改配置文件,根本就不需要修改代碼了,讓客戶代碼更穩(wěn)定。依賴關系肯定會存在,我們要做的就是降低依賴,想完全去除很難,也不現(xiàn)實。
抽象工廠模式的缺點:
有優(yōu)點肯定就有缺點,因為每種模式都有他的使用范圍,或者說要解決的問題,不能解決的問題就是缺點了,其實也不能叫缺點了?!境橄蠊S】模式很難支持增加新產(chǎn)品的變化,這是因為抽象工廠接口中已經(jīng)確定了可以被創(chuàng)建的產(chǎn)品集合,如果需要添加新產(chǎn)品,此時就必須去修改抽象工廠的接口,這樣就涉及到抽象工廠類的以及所有子類的改變,這樣也就違背了“開發(fā)——封閉”原則。
抽象工廠模式的使用場景:
如果系統(tǒng)需要多套的代碼解決方案,并且每套的代碼方案中又有很多相互關聯(lián)的產(chǎn)品類型,并且在系統(tǒng)中我們可以相互替換的使用一套產(chǎn)品的時候可以使用該模式,客戶端不需要依賴具體實現(xiàn)。
七、.NET中抽象工廠模式實現(xiàn)
微軟的類庫發(fā)展了這么多年,設計模式在里面有大量的應用,【抽象工廠】模式在.NET類庫中也存在著大量的使用,比如和操作數(shù)據(jù)庫有關的類型,這個類就是System.Data.Common.DbProviderFactory,這個類位于System.Data.dll程序集中。該類扮演抽象工廠模式中抽象工廠的角色,DbProviderFactory就是【抽象工廠】模式UML里面AbstractFactory類型。其他具體的工廠類型繼承DbProviderFactory類型。
到此這篇關于.Net設計模式之抽象工廠模式(Abstract Factory)的文章就介紹到這了。希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關文章
.NET?6更新使.NET生態(tài)系統(tǒng)蛻變
微軟正式發(fā)布.NET最新長期支持版本.NET?6,這個版本的更新重點,除了C#和F#都有許多語言功能改進之外,.NET?6終于集大成,成為跨瀏覽器、云計算、桌面、物聯(lián)網(wǎng)和移動應用程序的統(tǒng)一平臺,性能也獲得大幅提升,并且更完整支持Arm642022-01-01.net?6精簡版webapi教程及熱重載、代碼自動反編譯演示
這篇文章介紹了.net?6精簡版webapi教程及熱重載、代碼自動反編譯演示,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2021-12-12.Net中的不可變集合(Immutable Collection)程序集簡介
這篇文章介紹了.Net中的不可變集合(Immutable Collection)程序集,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2022-06-06ASP.NET Core應用程序配置文件AppSetting.json
這篇文章介紹了ASP.NET Core應用程序配置文件AppSetting.json,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2022-02-02