接口与继承:在这种情况下哪个更好？

Question

让我们假设我有一个小部件类：

struct Widget {
    public Color Color { get; set; }
    public int Frobbles { get; set; }
}

现在，我需要创建一个工厂来创建这些小部件，所以我构建了一个WidgetFactory：

abstract class WidgetFactory {
    public virtual Widget GetWidget();
}

事实证明，您可以使用几种不同的材料制作小部件，但是产生的小部件几乎是一样的。因此，我有几个WidgetFactory实现：

class GoldWidgetFactory : WidgetFactory {
    public GoldWidgetFactory(GoldMine goldmine) {
        //...
    }

    public Widget GetWidget() {
        Gold g = goldmine.getGold();
        //...
    }
}

class XMLWidgetFactory : WidgetFactory {
    public XMLWidgetFactory(XmlDocument xmlsource) {
        //...
    }

    public Widget GetWidget() {
        XmlNode node = //whatever
        //...
    }
}

class MagicWidgetFactory : WidgetFactory {
    public Widget GetWidget() {
        //creates widget from nothing
    }
}

我的问题是: WidgetFactory是一个抽象类还是一个接口？我可以看到两个方向的论点：

基类：

• 实现是WidgetFactories
• 它们可能能够共享功能(例如，List<Widget> WidgetFactory.GetAllWidgets()方法)。

接口：

• 实现不从父级继承任何数据或功能。
• 他们的内部运作完全不同
• 只定义了一个方法。

对于那些回答者，这(目前)并不平行于任何现实世界的问题，但是如果/当我需要实现这个模式时，最好知道。此外，“这不重要”是一个有效的答案。

编辑:首先，我要指出为什么要这样做。这个类层次结构的假设用法如下：

//create a widget factory
WidgetFactory factory = new GoldWidgetFactory(myGoldMine);

//get a widget for our own nefarious purposes
Widget widget = factory.GetWidget();

//this method needs a few widgets
ConsumeWidgets(factory);

因此，在GetGoldWidget()中使用WidgetFactory方法并不是一个好主意。另外，也许Widget技术的先进技术允许我们在将来添加不同的、更有异国情调的小部件？添加一个新的类来处理它们比在现有类中添加一个方法更简单、更简洁。

Answer 1

老实说，除了具体的工厂类之外，您还期望从WidgetFactory继承什么？有什么吗..。有没有过？如果不是的话，这可能根本不重要。如果您希望在它们之间添加公共代码，那么抽象类将是最好的选择。另外，除了创建方法之外，我并不认为工厂方法需要实现任何其他接口。所以不管是抽象的还是界面的。这都取决于将来您是否希望在抽象类中添加其他功能。

Answer 2

在您给出的示例中，WidgetFactory绝对没有理由成为抽象类，因为工厂的不同实现之间没有共享属性或方法。

即使有共享的功能，创建一个接口并将其传递给WidgetFactory的用户，以减少这些组件需要拥有的工厂知识的积累，也会更有成就感。

总体实现很好，实际上是一个抽象工厂模式，我要做的唯一补充就是IWidgetFactory。

public interface IWidgetFactory {
    Widget GetWidget();
}

abstract class WidgetFactory : IWidgetFactory {
    //common attributes and methods
}

//Defferent implementations can still inherit from the base abstract class
class GoldWidgetFactory : WidgetFactory {
    public GoldWidgetFactory(GoldMine goldmine) {
        //...
    }

    public Widget GetWidget() {
        Gold g = goldmine.getGold();
        //...
    }
}

Answer 3

在这种情况下，我认为使用抽象类而不是接口没有好处。

与抽象类相比，我通常更倾向于接口：

• 他们不会浪费你在课堂上的唯一机会
• 他们可以更容易嘲弄
• 他们在某种程度上觉得“更纯粹”(从接口上可以清楚地看到实现者需要提供什么；您不需要检查每一种方法是否是具体的、抽象的还是虚拟的)

但是，在这种情况下，您可以很容易地使用委托，因为只有一个方法.基本上是一个Func<Widget>。

我不同意Larry的想法，即只使用一个工厂直接创建具有不同方法的所有小部件--因为您可能希望将WidgetFactory作为一个依赖项传递给另一个类，该类不需要了解源，而是需要在不同的时间或可能多次调用CreateWidget。

但是，您可以有一个小部件工厂，其中包含多个方法，每个方法都返回一个Func<Widget>。这将提供一个工厂类的好处，同时也允许“工厂”概念的依赖注入。