在 .NET 中使用隐式转换替代多重继承

Question

我有一种情况，我希望某种类型的对象能够用作两种不同类型。如果“基本”类型之一是接口，这不会成为问题，但就我而言，最好它们都是具体类型。

我正在考虑将基类型之一的方法和属性的副本添加到派生类型，并添加从派生类型到该基类型的隐式转换。然后，用户将能够通过直接使用重复的方法、将派生类型分配给基类型的变量或将其传递给采用基类型的方法，将派生类型视为基类型。

看起来这个解决方案很适合我的需求，但是我错过了什么吗？是否存在这种情况不起作用，或者在使用 API 时可能会增加混乱而不是简单性？

编辑：有关我的具体场景的更多详细信息：

这是为了将来可能重新设计 RightEdge，这是一个自动交易系统开发环境。价格数据表示为一系列条形图，其中包含给定时间段（1 分钟、1 天等）的开盘价、最低价、最高价和收盘价的值。指标对一系列数据进行计算。简单指标的一个示例是移动平均指标，它给出其输入的最新 n 值的移动平均值，其中 n 是用户指定的。移动平均线可以应用于收盘价柱，也可以应用于另一个指标的输出以使其平滑。

每次出现新的柱时，指标都会计算该柱的输出的新值。

大多数指标只有一个输出系列，但有时有多个输出会很方便（请参阅MACD)，我想支持这一点。

因此，指标需要从“Component”类派生，该类具有新数据进入时调用的方法。但是，对于只有一个输出系列（这是其中的大多数）的指标，这对它们来说是有好处的自己充当一个系列。这样，用户就可以使用 SMA.Current 作为 SMA 的当前值，而不必使用 SMA.Output.Current。同样，Indicator2.Input = Indicator1; 优于 Indicator2.Input = Indicator1.Output;。这看起来似乎没有太大区别，但我们的许多目标客户都不是专业的 .NET 开发人员，所以我想让这尽可能简单。

我的想法是对于只有一个输出系列的指标，从指标到其输出系列进行隐式转换。

Answer 1

您没有提供太多详细信息，因此这里尝试根据您提供的内容进行回答。

看一下基本差异：
当您有基类型 B 和派生类型 D 时，如下所示的赋值：

B my_B_object = my_D_object;

将引用分配给同一对象。另一方面，当 B 和 D 是独立类型并且它们之间存在隐式转换时，上述赋值将创建 的副本>my_D_object 并将其存储在 my_B_object 上（如果 B 是一个类，则存储对其的引用）。

总之，“真正的”继承通过引用工作（对引用的更改会影响许多引用共享的对象），而自定义类型转换通常按值工作（这取决于您如何实现它，但实现接近“通过引用”的东西） “转换器的行为几乎是疯狂的）：每个引用都将指向它自己的对象。

你说你不想使用接口，但为什么呢？使用组合接口 + 辅助类 + 扩展方法（需要 C# 3.0 和 .Net 3.5 或更高版本）可以非常接近真正的多重继承。看看这个：

interface MyType { ... }
static class MyTypeHelper {
    public static void MyMethod(this MyType value) {...}
}

对每个“基本”类型执行此操作将允许您为所需的方法提供默认实现。

这些方法不会像开箱即用的虚拟方法一样运行；但你可以使用反射来实现这一点；您需要在 Helper 类的实现中执行以下操作：

1. 使用 value.GetType() 检索 System.Type
2. 查找该类型是否具有与 。
3. 如果找到匹配的方法，则调用它并返回（因此 Helper 方法的其余部分不会运行）
4. 最后，如果您没有找到具体的实现，请让该方法的其余部分运行并作为“基类实现”工作。

就是这样：C# 中的多重继承，唯一需要注意的是在支持此功能的基类中需要一些丑陋的代码，以及由于反射而产生的一些开销；但除非您的应用程序在很大的压力下工作，否则这应该可以解决问题。

那么，再一次，为什么你不想使用接口呢？如果唯一的原因是他们无法提供方法实现，上面的技巧就可以解决它。如果您对接口有任何其他问题，我可能会尝试解决它们，但我必须首先了解它们；）

希望这会有所帮助。

---

[编辑：根据评论添加]

我在原来的问题中添加了一些细节。我不想使用接口，因为我想防止用户因为错误地实现接口而搬起石头砸自己的脚，或者意外地调用一个方法（即 NewBar），如果他们想要实现一个指示器，他们需要重写该方法，但他们永远不需要直接调用。

我已经查看了您更新的问题，但评论非常概括了它。也许我错过了一些东西，但是接口+扩展+反射可以解决多重继承可以解决的所有问题，并且在任务中比隐式转换要好得多：

• 虚拟方法行为（提供了实现，继承者可以重写): 在帮助器上包含方法（包装在上面描述的反射“虚拟化”中），不要在接口上声明。
• 抽象方法行为（没有提供实现，继承者必须实现）：在接口上声明方法，不要将其包含在帮助器中。
• 非虚拟方法行为（提供了实现，继承者可以隐藏但不能覆盖）：只需在帮助器上正常实现即可。
• 奖励：奇怪的方法（提供了一个实现，但继承者无论如何都必须实现；他们可以显式调用基本实现）：这对于普通继承或多重继承来说是不可能的，但为了完整性我将其包括在内：如果您在助手上提供实现并在接口上声明它，就会得到这样的结果。我不确定它是如何工作的（在虚拟与非虚拟方面）或者它有什么用途，但是嘿，我的解决方案已经击败了多重继承：P

注意：在这种情况下对于非虚拟方法，您需要将接口类型作为“声明”类型以确保使用基本实现。这与继承者隐藏方法完全相同。

我想防止用户因为错误的实现而搬起石头砸自己的脚

似乎非虚拟（仅在助手上实现）在这里效果最好。

或者意外地调用了一个方法（即 NewBar），如果他们想要实现指标，则需要重写该方法

这就是抽象方法（或接口，这是一种超抽象的东西）最闪耀的地方。继承者必须实现该方法，否则代码甚至无法编译。在某些情况下，虚拟方法可能会这样做（如果您有一个通用的基本实现，但更具体的实现是合理的）。

但他们永远不需要直接调用

如果一个方法（或任何其他成员）暴露给客户端代码但不应该从客户端代码调用，则没有编程解决方案来强制执行该操作（实际上，有，请耐心等待）。解决这个问题的正确位置是在文档中。因为您正在记录您的API，不是吗？ ;) 转换和多重继承都无法帮助您。但是，反射可能会有所帮助：

if(System.Reflection.Assembly.GetCallingAssembly()!=System.Reflection.Assembly.GetExecutingAssembly())
    throw new Exception("Don't call me. Don't call me!. DON'T CALL ME!!!");

当然，如果文件中有 using System.Reflection; 语句，则可以缩短该时间。而且，顺便说一句，请随意将异常的类型和消息更改为更具描述性的内容；）。

Answer 2

我发现两个问题：

• 用户定义的类型转换运算符通常不太容易被发现——它们不会出现在 IntelliSense 中。

• 对于隐式用户定义类型转换运算符，应用该运算符时通常不明显。

  对于

这并不是说您根本不应该定义类型转换运算符，但在设计解决方案时必须牢记这一点。

一个易于发现、易于识别的解决方案是定义显式转换方法：

class Person { }

abstract class Student : Person
{
    public abstract decimal Wage { get; }
}

abstract class Musician : Person
{
    public abstract decimal Wage { get; }
}

class StudentMusician : Person
{
    public decimal MusicianWage { get { return 10; } }

    public decimal StudentWage { get { return 8; } }

    public Musician AsMusician() { return new MusicianFacade(this); }

    public Student AsStudent() { return new StudentFacade(this); }
}

用法：

void PayMusician(Musician musician) { GiveMoney(musician, musician.Wage); }

void PayStudent(Student student) { GiveMoney(student, student.Wage); }

StudentMusician alice;
PayStudent(alice.AsStudent());

Answer 3

听起来您的方法似乎不支持交叉转换。真正的多重继承会。

来自 C++ 的示例，具有多重继承：

class A {};
class B {};
class C : public A, public B {};

C o;
B* pB = &o;
A* pA = dynamic_cast<A*>(pB); // with true MI, this succeeds

Answer 4

然后，用户将能够通过直接使用重复的方法、将派生类型分配给基类型的变量或将其传递给采用基类型的方法，将派生类型视为基类型。

然而，这会表现不同。在继承的情况下，您只需传递对象。但是，通过实现隐式转换器，在转换发生时您将始终构造一个新对象。这可能是非常出乎意料的，因为在这两种情况下它的表现会完全不同。

就我个人而言，我会将其设为返回新类型的方法，因为它将使最终用户清楚实际的实现。

Answer 5

也许我对此太过分了，但您的用例听起来很可疑，好像它可以从 Rx (15 分钟内接收）。

Rx 是一个用于处理生成值的对象的框架。它允许这些对象以一种非常富有表现力的方式组合，并转换、过滤和聚合这些产生的值流。

您说您有一个柱：

class Bar
{
    double Open { get; }
    double Low { get; }
    double High { get; }
    double Close { get; }
}

系列是生成柱的对象：

class Series : IObservable<Bar>
{
    // ...
}

移动平均线指标是每当生成新柱时生成最后 count 柱的平均值的对象：

static class IndicatorExtensions
{
    public static IObservable<double> MovingAverage(
        this IObservable<Bar> source,
        int count)
    {
        // ...
    }
}

用法是如下：

Series series = GetSeries();

series.MovingAverage(20).Subscribe(average =>
{
    txtCurrentAverage.Text = average.ToString();
});

具有多个输出的指标类似于 GroupBy。

Answer 6

这可能是一个愚蠢的想法，但是：如果您的设计需要多重继承，那么为什么不简单地使用具有 MI 的语言呢？有多种 .NET 语言支持多重继承。我的脑海中浮现出：Eiffel、Python、Ioke。可能还有更多。