橋樑或工廠模式？

在我的設計中，我第一次設計了一個工廠模式。但一個人推薦使用更好的橋接模式。橋樑或工廠模式？

這是我的情景：How to improve my abstract factory pattern?

我只是想知道哪個模式是最適合這個場景..我越來越糊塗！

我的情況的總結是：

試想一個黑盒子，這個黑盒子接收一個名爲 Configuration對象，並將其輸出爲Problem對象

一開始我是這個黑盒子打電話給一家工廠，但後來我需要用我的抽象類中的泛型更具體，所以，一個人告訴我更好地使用這個橋。

此外，在我的工廠中，需要在構造函數中接收輸入值，並且還可以修改實例..因此這部分是後期。

我不會非常喜歡那種模式，所以我只想使用這個簡短的場景，我該做什麼？

來源

2012-03-29 Darf Zon

請您發佈*此場景的摘要*？ – oleksii 2012-03-29 19:05:57

@oleksii當然，讓我加！ – 2012-03-29 19:07:07

你不想要一座橋。它曾經有一個接口可以使用多個實現。這允許在用戶不知道它的情況下切換實現。您想要使用問題和配置工廠的相鄰。

如果您想在不知道用戶的情況下使用問題和配置部分進行切換，那麼您可以使用橋接器。

請記住，您可以使用盡可能多的模式在同一時間，只要你想，也在這種情況下，你不必被迫選擇。使用你認爲最有效的方法。

來源

2012-03-29 19:12:47 MrFox

更重要的是...不用擔心解決問題*使用模式X *。只要解決問題。如果模式X是自然的解決方案，它將無論如何（以某種形式出現）。 – cHao 2012-03-29 19:15:53

@cHao我真的很喜歡這最後的評論。我想有時候我很複雜，因爲我正在尋找正確的模式，但正如你所說，模式是天生的！ – 2012-03-29 23:26:29

您可以使用參數化的工廠模式，我不確定Bridge是否旨在解決您的問題。

interface IFactory<TConfiguration,TProblem> 
      where TProblem: IProblem 
      where TConfiguration: IConfiguration 
{ 
    TProblem Create(TConfiguration config); 
} 

class Factory<TConfiguration,TProblem>: IFactory<TConfiguration,TProblem> 
      where TProblem: IProblem 
      where TConfiguration: IConfiguration 
{ 
    TProblem Create(TConfiguration config) 
    { 
     var problem = new Problem(config); 
     ... 
     return problem; 
    } 
}

_{寫在記事本NB代碼，因此可能無法編譯，但我希望這個想法是明確}

來源

2012-03-29 19:22:54 oleksii

我一開始就是這麼想的。我懷疑是因爲我的界面是通用的，我見過很多這樣的類，但最低的類是非泛型類。所以這沒關係？ – 2012-03-29 20:57:52

技術上講，它並不真正的問題在這裏，我不認爲你的架構將從中受益切換到橋。原因如下：

當您的層次結構具有兩個不同自由度時，橋接器很有用 - 看起來您的系統具有：第一個是問題，第二個是配置。

在橋上，你會提取一個層次，並將其注入到另一個層次中。因此，例如你有一個抽象類Problem有自己的層次結構（ProblemA，VeryDifficultProblem）和你注入從其他層級（ConcreteConfiguration1等）實現

什麼是這裏的關鍵是兩個層次。如果你的問題沒有形成類的層次結構，而是你想要用接口指定契約（這樣實現的類可能來自不同的子樹），那麼Bridge就會不自然，我會堅持工廠。我不認爲Bridge在用接口而不是抽象類來實現時有很多意義。

來源

2012-03-29 19:27:57

橋樑或工廠模式？

回答

相關問題