何時使用工廠模式而不是重載構造函數來實例化對象會更有意義？

在Karl Seguin的Foundations of Programming有一小部分關於使用工廠模式。他通過陳述「您可以用構造函數重載完成相同的功能」來關閉段落，但並未指出何時或爲什麼？何時使用工廠模式而不是重載構造函數來實例化對象會更有意義？

那麼，什麼時候使用工廠模式而不是重載構造函數來實例化對象會更有意義？

來源

2009-10-09 JaredCacurak

在Karl的辯護中，他表示工廠模式提供了更好的可讀性，但他使用他的「腸道」和「味道」作爲決定性因素。 – JaredCacurak 2009-10-09 00:51:35

如果你想擁有鬆散耦合則工廠更有意義，因爲你就可以只需要調用汽車廠，通過在SUV枚舉，並返回正確的類。只要滿足您的需求，您的應用程序不關心哪個類實際返回。

來源

2009-10-09 00:50:43

接受工廠作爲參數的對象也負責調用創建方法。 – JaredCacurak 2009-10-14 17:14:30

當我想要工廠構造幾個不同的可能子類之一（並且我希望調用者知道基類但不知道子類）時，我使用了一個工廠。

另外，偶爾我會使用類，而不是一個重載的構造函數，靜態方法，當不同的靜態方法，採取相同的參數類型（因此構造函數不能僅根據參數類型重載）。這裏是一個人爲的例子：

Department 
{ 
    //static factory methods 
    public static Department createFromBoss(string bossName) { ... } 
    public static Department createFromLocation(string locationName) { ... } 
}

來源

2009-10-09 00:50:13 ChrisW

我有1個工廠有用的情況。我必須實例化視頻效果才能在視頻上運行。視視頻類型而定，視頻效果具有不同的具體類別。

如果我實例化具體類，那麼我將失去在不修改實例化代碼的情況下添加更多視頻效果的能力。

當我添加更多的視頻效果，我只需要修改工廠選擇適當的具體類。

這是否有意義？

來源

2009-10-09 00:50:47

這可能是工廠有時會生成返回類型的子類型。你不能用構造函數來做到這一點，但要有工廠的靈活性。

來源

2009-10-09 00:59:51

如果您在做Dependency Injection，但需要在依賴項中根據需要創建依賴項的實例，則一個選項是將接口注入到類工廠。工廠可以返回一個接口或一個抽象類。這以一些複雜性爲代價提供了靈活性，可測試性和解耦。

來源

2009-10-09 02:12:00 TrueWill

的確如果沒有某種語言的工廠/生成器（C++），虛擬建設就無法實現 – 2009-10-09 14:42:52

我不同意他的發言。當你有不同的構造/初始化構造函數的方法時，會使用不同的構造函數。當初始化標準導致您有不同的對象構造時，將使用工廠模式。

來源

2009-10-09 11:44:57

如ChrisW所示，如果要通過您的方法實現多態性，使用工廠模式使用子類也更有意義。如果

Department b = Department.createFromBoss(); 
Department l = Department.createFromLocation();

都返回不同的子類系的話，

b.Close()

和

l.Close()

例如可以採取不同的行動，如果你有嘗試和關閉這將是梅西耶（）通過構造函數重載的單個對象。

來源

2009-10-12 02:20:24

何時使用工廠模式而不是重載構造函數來實例化對象會更有意義？

回答

相關問題