接口和类的继承。这是一种可以避免的模式吗？

Question

对于在以下情况下应采取哪种方式，我将不胜感激。让我们看看我是否能解释清楚（英语不是我的母语，所以事情可能会变得混乱，抱歉）。

假设我有以下接口：

internal interface IBlah
{
     int Frob();
}

internal interface IBlahOnSteroids: IBlah
{
     double Duh();
}

现在我们有一个 Foo 类，与 IBlah 对象具有“has a”关系：

public class Foo
{
     IBlah blah;

     internal Foo(IBlah blah)
     {
          this.blah = blah;
     }

     public int Frob()
     {
          ....
          return this.blah.Frob();
     }
}

现在我们还需要一个 FooOnSteroids 类，它与 IBlahOnSteroids 对象具有“has a”关系。 问题是，知道 IBlahOnSteroids 的一部分已经在 Foo 中实现，如果我们创建会发生什么 FooOnSteroids 继承自 Foo？

我们会得到这样的信息：

public class FooOnSteroids: Foo
{
    IBlahOnSteroids blah;

    internal FooOnSteroids(IBlahOnSteroids blah)
        :base(blah) 
    {
         this.blah = blah;
    }

    public double Duh()
    {
         return this.blah.Duh();
    }
}

这是推荐的模式吗？我们在继承链上传递相同的“blah”对象，并且在每个“级别”我们将其存储在私有对象中 具有“有用”类型的字段。我认为我不可能将受保护的财产存储在 BlahBase 中 公开了对所有降序类的一个常见的 IBlah 引用，因为它必须是 IBlah 类型，这对 BlahOnSteroids 没有任何用处。这情景还算吗 受到推崇的？或者我们应该将 Foo 和 FooOnSteroids 实现为没有继承的独立类（这会造成代码重复）？也许这样做绝对没问题，但不知何故感觉像是黑客攻击。是吗？

使用泛型的选项可以立即解决问题，但这是不可能的，因为，是的，我知道这很糟糕，这个库必须针对 .Net 1.x 平台。

仅实现 BlahOnSteroids 的选项也是一种可能性，但这意味着根据调用者的不同，如果出现以下任何情况，我们将不得不抛出异常： IBlahOnSteroids 成员被称为。我不喜欢这样。

非常感谢您的任何建议！

Answer 1

您可以通过使基本字段可用来减少重复：

IBlah blah;
protected IBlah Blah { get { return blah; } }

并在子类型上进行强制转换（因为您希望您选择的 blah 得到尊重）：

public double Duh() {
    return ((IBlahOnSteroids)Blah).Duh();
}

您还可以在基本字段上使用泛型做一些事情 -输入（以避免强制转换），但我不确定它是否值得。但请注意，如果基类决定注入大量的装饰器（如果装饰器不提供第二个接口），这可能会爆炸。

Answer 2

一种替代模式是

public class Foo
{
    protected IBlah Blah { get; private set; }
    ...
}
public class FooOnSteroids : Foo 
{
    private new IBlahOnSteroids Blah { get { return (IBlahOnSteroids)base.Blah; } }
    ...
}

然而，这与您的代码没有太大不同；如果你不能使用泛型，它们都可以。

Answer 3

针对您关于删除 Foo 和 FooOnSteroids 之间的继承的问题，我不知道您所有的推理，但我可以尝试提供一些一般性指导。您应该考虑使用继承，主要是为了向您的客户提供使用 FooOnSteroids 实例的能力，但只为 Foo 编写代码。

因此，如果从概念上讲您的客户这样做：

Foo foo = new FooOnSteroids();
foo.Frob()

您应该保留继承权。

如果您只是为了重用代码而创建继承关系，我建议您考虑重构这些类以包含提供共享功能的类。继承并不是代码重用的最佳模式。

Answer 4

鉴于您不能使用泛型（这可能会或可能不会使您的特定用例变得更容易），我个人会选择转换 Foo 的 blah 成员。 C# 中的转换相对轻松：

public double Duh()
{
    return (this.blah as IBlahOnSteroids).Duh();
}

如果无法将对象转换为您请求的类型，则 C# 中的 as 关键字将计算为 null。在上面的示例中，如果 this.blah 不是 IBlahOnSteroids 的实例，您将收到 NullReferenceException。您可以检查一个对象是否是某个类型的实例，如下所示：

public double Duh()
{
    if (this.blah is IBlahOnSteroids)
        return (this.blah as IBlahOnSteroids).Duh();
    else
        throw new InvalidTypeException("Blah is not an instance of IBlahOnSteroids");
}

尽管在原始示例的代码中，blah 不可能可能不是一个实例的 IBlahOnSteroids ，因为它是在构造函数中分配的，这会在编译时为您做出该断言。