廠的說法，並傳遞給它的參數來初始化它創建

拆離從類確切的實現細節客戶端代碼。
集中創建代碼，所以如果創建邏輯發生變化，它只會在工廠中更改，而不是可能的20個文件。

但是如果我想傳遞特定的參數給構造函數來正確初始化它呢？這將來自應用程序的用戶或當前狀態。這不會打敗第二點嗎？

class AnimalFactory 
{ 
public: 
    createAnimal(type, string nickName) 
    { 
     if (type == 0) 
      return new Dog(nickName); 
     else if(type == 1) 
      return new Cat(nickName); 
    } 
}

以上是我如何在實施例中看到的，但是以下同樣好的工廠，甚至更優選的，因爲其更具有可讀性和傳遞少一個參數？

class AnimalFactory 
{ 
public: 
    createDog(string nickName) 
    { 
     return new Dog(nickName); 
    } 

    createCat(string nickName) 
    { 
     return new Cat(nickName); 
    } 
}

來源

2016-02-26 zar

這取決於使用情況。

無論如何，在第二個版本中，我沒有看到直接調用構造函數的好處。
似乎它唯一的好處是能夠將此功能放入map。

在第一個版本中，map可以是facory方法的實現細節。

來源

2016-02-26 06:46:06 Qwertiy

工廠模式的要點是通過暴露穩定的接口來創建對象時隱藏易變的東西。您的兩個工廠都隱藏類型Dog & Cat，並顯示抽象類型Animal。這很好。

第二個工廠的可讀性更強，但如果它的接口發生了變化呢？例如，當您添加新方法createElephant時，您不需要關心Elephant的某些客戶端代碼仍需要重新編譯和重新部署。在這種情況下，雖然第一工廠的可讀性較差，但它更好。

因此，工廠的選擇取決於代碼更改的可能性。請記住保持工廠界面穩定。

來源

2016-02-26 11:16:35 Kata

嗯，這是我不明白的理由。如果我必須創建新的'Elephant'類型，我將不得不創建一個新的'類型'，它將被傳遞到工廠以創建它，所以代碼會發生變化！？如果這還不夠，想象一下大象，我需要傳遞它的「牧羣名稱」，這也需要更改代碼。這就是爲什麼我不能充分認識到這個工廠的優勢。 – zar

這是工廠界面的簽名改變。這使得工廠的一些客戶不必要地受到影響，因爲他們從不想創造大象。對於「受影響」，我的意思是重新編譯和重新部署，而不是客戶端的源代碼更改。的確，這些代碼不會改變:) – Kata

廠的說法，並傳遞給它的參數來初始化它創建

回答

相關問題