工廠方法何時比簡單工廠更好，反之亦然？

Question

通過Head First Design Patterns書籍工作。

我相信我理解簡單工廠和工廠方法，但是我很難看到工廠方法對簡單工廠有什麼優點。

如果對象A使用一個簡單的工廠來創建其乙對象，那麼客戶端可以這樣創建：

A a = new A(new BFactory()); 

而如果一個對象使用工廠方法，客戶機可以這樣創建：

A a = new ConcreteA(); // ConcreteA contains a method for instantiating 
         // the same Bs that the BFactory above creates, with 
         // the method hardwired into the subclass of A, ConcreteA. 

所以在簡單工廠的情況下，客戶端組成A，與乙工廠，而與工廠的方法，所述客戶端選擇爲它想要的類型B的適當子類。

他們之間似乎沒有多少選擇。要麼你必須選擇你想要編寫的BFactory，或者你必須選擇A的正確子類來爲你提供Bs。

在什麼情況下比另一個好？

謝謝大家！

編輯：增加一點混亂海事組織是在首腦敘述中給出的解釋，他們從簡單的工廠過渡到工廠方法，通過說（第119頁）「特許經營企業正在使用您的[簡單]工廠創建比薩餅，但開始採用他們自己的本土程序進行其餘的過程：他們會烘烤一些不同的東西。「他們有一張廚師的照片，顯然他做了一些令他厭惡的比薩餅。

但是沒有關於使用一個簡單的工廠，讓客戶訪問bake（）方法或過程的任何其他部分。而且沒有關於使用工廠方法的問題，如果它有任何問題，這些方法都會有所幫助。

所以看起來我喜歡它的原因深入淺出意味着使用一個工廠方法在一個簡單的工廠是假的..

Answer 1

在117頁和131點是比較UML圖，簡單廠決定如何爲PizzaStore烤比薩餅。工廠方法允許混凝土PizzaFactory決定如何烘烤披薩。工廠是關於管理依賴關係的。使用構造函數，你必須決定實例化哪個類。使用簡單的工廠，你可以讓具體的類來決定實例化哪個類。使用Factory方法，你讓任何類（可以）決定實例化哪個類。使用抽象工廠，您可以讓任何類（可以）決定要實例化哪個類，而不管您想要創建什麼類型的實例。控制的倒置正在使用你得到的東西，因爲決定是在神聖的存在創造你時做出的。

我的個人意見是，GoF的原創設計模式書雖然不擅長解釋，但有更多的現實世界的例子。

Answer 2

分析不同角色的差異：A的用戶和A的提供者。這些模式對這些角色具有不同的含義，隨着時間的推移，這些角色會發生顯着變化。

在A的

A myA = new SomeConcreteA() 

客戶的情況一無所知的事實，甚至燒烤存在。特定混凝土A的選擇可能會受到某些文檔的影響，這些文檔使用特定B或A系列的某些完全其他特徵。 A的提供者負責創建具體的A的所有口味，所以當B類變化時他們可能有工作要做。

在

A myA = new A(myBFactory()) 

的情況下，客戶現在需要了解燒烤和他們的工廠，擁有超過使用哪個工廠的完全控制。提供商給予客戶更多的責任，而且我們可能已經增加了耦合 - 客戶代碼現在明確依賴於至少一個類。當新的B出現時，A的提供者沒有工作要做。

請注意，我們正在注入B工廠，所以在編寫客戶端單元測試時，我們現在可以更輕鬆地爲Bs提供模擬，因此測試客戶端往往更容易。總的來說，我發現我更頻繁地使用這種注射方法。

Answer 3

你說得對，因爲從簡單工廠到工廠方法的所有變化都是在Simple Factory中工廠通過構造函數傳入的，我們用它來創建我們的對象。在Factory Method中，現在調用抽象工廠類中的抽象方法;但這是強大的。由於該方法是抽象的，它必須在我們的子類中實現，這正是我們所期望的。我們的子類可以實現它們自己的變體，但某些行爲仍然由我們的抽象類實施。更強大的是，我們可以在不修改原始代碼的情況下擴展工廠數量，只需添加從抽象基類繼承的新類即可。