抽象工廠模式

這是關於抽象工廠模式。抽象工廠模式

正如我們所知，有2種方式，我們可以使用即

無論是創建具體的類的實例直接或
提供通過它我們可以訪問具體類的接口

有人能說出優勢/劣勢，如果我使用選項1，那麼這些是可能發生的問題，反之亦然，如果可能的話用實時示例。

在此先感謝...

2010-06-11 Amit

look up here http://stackoverflow.com/questions/2280170/why-do-we-need-abstract-factory-design-pattern – Arseny 2010-06-11 12:16:45

抽象工廠模式的存在使您不必硬編碼實例化的具體直接進入你的代碼。而是委託給創建「產品」的工廠對象。所以我不確定你是什麼意思的Option1。 – Gishu 2010-06-11 12:22:03

如果您有一個具體的類，它不是子類，並且您確信它永遠不會存在，那麼您可以將其實例化爲您的選項1 - 因爲這不需要工廠。

如果你有幾個具體的子類的接口/抽象類，並希望能夠改變的實現不佔用客戶任何人 - 這是當你使用一個factory（或dependency injection）。

來源

2010-06-11 12:33:19

直接創建對象肯定是容易（在C＃示例）：

public class Consumer() 
{ 
    public void DoStuff() 
    { 
     var f = new Foo() 
     f.DoIt("bar"); 
    } 
}

雖然簡單，它會導致緊耦合，因爲你不能獨立於消費者改變實例。

雖然是更復雜，使用抽象工廠消費是鬆耦合：

public class Consumer() 
{ 
    private readonly IFooFactory fooFactory; 

    public Consumer(IFooFactory fooFactory) 
    { 
     if (fooFactory == null) 
     { 
      throw new ArgumentNullException("fooFactory"); 
     } 

     this.fooFactory = fooFactory; 
    } 

    public void DoStuff() 
    { 
     var f = this.fooFactory.Create(); 
     f.DoIt("bar"); 
    } 
}

這看起來瘋狂的比第一個版本更復雜，但現在你可以獨立變化的f實施的Consumer。

你不僅能夠變化實施，但你也重用能夠或份額不同消費者之間實例。

在很多情況下，您不需要抽象工廠來啓用鬆耦合。通常情況下，您可以直接向消費者注入依賴關係，而不是訴諸額外的間接級別。

來源

2010-06-11 12:31:52

抽象工廠模式

回答

相關問題