c# - 接口(interface)与继承:在这种情况下哪个更好？

假设我有一个widget类：

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应该是抽象类还是接口？我可以从两个方面看到争论：
基类：
实现是widgetfactures
它们可能能够共享功能（例如，aList<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);

因此，在widgetfactory中使用GetGoldWidget()方法不是一个好主意。另外，也许微件技术的冒险允许我们在未来添加不同的、更奇特的微件类型？添加一个新的类来处理它们比将一个方法拖到现有的类中更容易和更干净。

最佳答案

老实说，除了具体的工厂类之外，您还希望从widgetfactory继承什么？有什么事吗？…曾经吗？
如果不是的话，那就没关系了。
如果您希望在它们之间添加公共代码，那么最好使用抽象类。
另外，我不认为您的工厂方法需要实现任何其他接口，除了您的创建方法。所以不管是抽象的还是接口的。这一切都取决于将来是否希望在抽象类中添加其他功能。