桥梁或工厂模式？

在我的设计中，我第一次设计了一个工厂模式。但一个人推荐使用更好的桥接模式。桥梁或工厂模式？

这是我的情景：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

桥梁或工厂模式？

回答

相关问题