更新時間:2022-06-08 10:00:57 來源:動力節點 瀏覽999次
工廠模式是“工廠是用于創建其他對象的對象”。簡單工廠模式是Factory最簡單形式的類(與工廠方法模式或抽象工廠模式相比)。換句話說,我們可以說:在簡單工廠模式中,我們有一個工廠類,它有一個方法可以根據給定的輸入返回不同類型的對象。
讓我們通過一個例子來理解:
為了實際理解簡單工廠模式,我們以制造不同類型風扇的電氣公司為例,我們將其稱為FanFactory。但首先,我們將在不使用簡單工廠模式的情況下實現此場景,然后會看到問題以及如何使用此模式解決這些問題。
下面的程序是一個簡單的控制臺應用程序,在這個程序中,Main方法用作創建一個TableFan. 在最簡單的實現中,我們可以看到客戶端能夠TableFan根據需要直接創建一個(無需任何工廠)。
class Program
{
static void Main(string[] args)
{
TableFan fan = new TableFan();
fan.SwitchOn();
}
}
class TableFan { }
在上面的示例中,我們沒有使用任何模式并且應用程序運行良好。但是如果我們考慮未來可能的變化并仔細觀察,我們可以預見到當前實現存在以下問題:
在當前的應用程序中,無論哪里需要特定的風扇,它都是使用具體類創建的。將來,如果有任何更改是類名/提出了不同的具體類,您必須在整個應用程序中進行更改。例如TableFan,我們不需要引入類,而是引入BasicTableFan(現在應該使用它來代替舊TableFan類)和PowerTableFan類。因此,對Fan類的任何更改都會使代碼難以維護,并且需要在許多地方進行許多更改。
目前,當客戶端創建TableFan對象時,TableFan類的構造函數不帶任何參數,因此Fan創建過程很容易。但是后來TableFan的對象創建過程發生了變化,如果Fan類的構造函數期望兩個對象作為參數怎么辦。然后代碼客戶端中的每個地方都需要在Fan創建對象的地方進行更改。例如:
TableFan fan = new TableFan(Moter moter, BladType bladType);
在創建對象TableFan fan = new TableFan(Moter moter, BladType bladType);時的代碼Fan中,它有兩種類型Moter,BladType. 在上面的代碼中,客戶端知道類,也知道對象的創建過程,這應該是FanFactory. 我們應該避免將此類對象創建細節和內部類暴露給客戶端應用程序。
在某些情況下,必須集中對已創建對象的生命周期管理,以確保應用程序內的行為一致。如果客戶可以按照自己的意愿自由創建具體對象,則無法做到這一點。這種情況經常發生在緩存管理和 DI 框架中。
在 C# 和 Java 中,類的構造函數必須與該類的名稱相同。假設需要為構造函數提供描述性名稱,例如CreateTableFanByModelNumber(int modelNumber). 在TableFan課堂上,我們最多可以有一個類似的構造函數, Fan(int modelNumber)但名稱不像它的意圖那樣具有描述性。另一個關于描述性名稱問題的類似示例也可在此維基百科頁面上找到。
為了解決上述問題,我們可以使用簡單工廠模式,因為這種模式適合解決上述問題。此外,我們將繼續使用相同的示例并修改現有代碼。
當我們實現簡單工廠模式時,需要創建一個類,該類將具有返回請求的對象實例的方法。讓我們創建一個名為“ FanFactory”的類,它將實現一個名為“ IFanFactory”的接口。這個接口有一個方法被調用IFan CreateFan(FanType type);,它接受enum FanType并返回 a 的各個實例Fan。
現在Client將不知道具體的類,如TableFanor CeilingFan。客戶將使用FanType enumand IFan interface。基于在enum調用“ CreateFan”方法時作為參數傳遞,FanFactory將返回所需風扇的實例。以下是修改后的應用程序代碼:
enum FanType
{
TableFan,
CeilingFan,
ExhaustFan
}接口IFan
{ void SwitchOn ();
無效開關();
} class TableFan : IFan {.... } class CeilingFan : IFan {.... } class ExhaustFan : IFan {..... } interface IFanFactory
{
IFan CreateFan(FanType type);
} class FanFactory : IFanFactory
{ public IFan CreateFan(FanType type)
{ switch (type)
{ case
FanType.TableFan:
return new TableFan();
case FanType.CeilingFan:
return new CeilingFan();
case FanType.ExhaustFan:
return new ExhaustFan();
默認:
返回 新的TableFan();
}
}
} //客戶端代碼如下:static void Main(string[] args)
{
IFanFactory simpleFactory = new FanFactory();
//
使用簡單工廠
創建風扇 IFan fan = simpleFactory.CreateFan(FanType.TableFan); //使用創建的對象
fan.SwitchOn();
Console.ReadLine();
}
現在我們將在“沒有實現簡單工廠模式的問題”部分確認簡單工廠模式如何解決上述所有問題:
現在客戶端正在使用接口和,所以如果我們更改為給定值創建FanFactory的具體類的名稱,我們只需要在一個地方進行更改,即在“ ”方法內部。客戶端代碼完全不受影響。FanenumCreateFanFanFactory
如果稍后,Fan對象創建過程發生變化并且Fan類的構造函數期望兩個或多個對象作為參數,我們只需要在 的 " CreateFan" 方法內進行更改FanFactory。客戶端代碼完全不受影響。
使用FanFactory,所有內部細節將對客戶隱藏。所以它在抽象和安全方面是好的。
如果需要,我們可以編寫生命周期管理邏輯以及集中式對象創建FanFactory。
在使用時FanFactory,我們可以簡單地使用具有不同且更具描述性名稱的方法,這些方法將返回IFan. 在我們的示例應用程序中,FanFactory可以將公共方法CreateTableFanByModelNumber(int modelNumber)公開給客戶端。
以上就是關于“簡單工廠模式的詳細介紹”,大家如果對此比較感興趣,想了解更多相關知識,不妨來關注一下動力節點的Java設計模式,里面有更豐富的知識等著大家去學習,相信對大家會有所幫助的。
0基礎 0學費 15天面授
有基礎 直達就業
業余時間 高薪轉行
工作1~3年,加薪神器
工作3~5年,晉升架構
提交申請后,顧問老師會電話與您溝通安排學習