.NET 中多重继承有哪些好的替代方案？

Question

我在 WPF 应用程序中的类层次结构中遇到了一些问题。这是其中一个问题，其中两个继承树合并在一起，并且您无法找到任何逻辑方法来使您的继承在没有多重继承的情况下顺利工作。我想知道是否有人有任何好主意来让这种系统正常工作，而又不会使其无法遵循或调试。

我是一名低级工程师，所以我的第一个想法总是，“哦！我只需用本机 C++ 编写其中一些类，并在外部引用它们！然后我就可以享受所有老式 OO 的乐趣了！”唉，当您需要从托管控件继承时，这没有帮助...

请允许我显示我当前投影的类图的片段：

 ____________________________________      _____________________________________
| CustomizableObject                 |    | System.Windows.Controls.UserControl |
|____________________________________|    |_____________________________________|
|   string XAMLHeader()              |                        ▲
|   string XAMLFooter()              |◄--┐                    |
|   CustomizableObject LoadObject()  |   \                    |
|   <Possible other implementations> |    \                   |
|____________________________________|     \                  |
         ▲                      ▲           \                 |
         |                      |            \                |
         |                      |             \               |
 _________________    ______________________   \    _____________________
| SpriteAnimation |  | SpriteAnimationFrame |  └---| CustomizableControl |
|_________________|  |______________________|      |_____________________|
                                                      ▲             ▲
                                                      |             |
                                                      |             |
                                                  ________    _____________
                                                 | Sprite |  | SpriteFrame |
                                                 |________|  |_____________|

问题非常清楚：CustomizedObject 和 CustomizedControl 对象树的分离 --- 和将 UserControl 插入一棵树中，但不是两棵树中。

将 CustomizedObject 的实现移至其派生类中没有实际意义，因为实现不会因类而异。此外，多次实施确实会造成混乱。所以我真的不想让CustomizedObject成为一个接口。界面解决方案对我来说没有任何意义。 （老实说，界面从来对我来说从来没有真正有意义......）

所以我再说一遍，有人有什么好主意吗？这是真正的泡菜。我想了解更多关于如何使接口与我的对象树一起工作，而不是反对它。我正在使用 WPF 和 C# 制作这个简单的精灵引擎，作为一项扎实的练习，这比什么都重要。这在 C++ 中很容易解决 - 但我需要弄清楚如何在托管环境中解决这些问题，而不是每当事情变得困难时就举手投足并跑回 Win32。

Answer 1

这里你有两个选择；使用接口，或者使用组合。老实说，接口非常强大，读完这一行后

界面解决方案对我来说没有任何意义。 （说实话，界面对我来说从来没有真正意义......）

我认为你应该学习如何正确使用它们。也就是说，如果只是多个类需要一些逻辑，但这些类从同一个基类继承没有意义，只需创建一个类来封装该逻辑并将该类的成员变量添加到您的类中这给你带来了问题。这样，所有类都包含逻辑，但可以在其继承层次结构中分开。如果类应该实现公共接口，则使用接口。

Answer 2

一种方法是使用带有接口的扩展方法来提供“派生类”实现，就像 System.Linq.Queryable 一样：

interface ICustomizableObject
{
    string SomeProperty { get; }
}

public static class CustomizableObject
{
    public static string GetXamlHeader(this ICustomizableObject obj)
    {
        return DoSomethingWith(obj.SomeProperty);
    }

    // etc
}

public class CustomizableControl : System.Windows.Controls.UserControl, ICustomizableObject
{
    public string SomeProperty { get { return "Whatever"; } }
}

用法： 只要您有一个 using 指令（或在与定义扩展方法的名称空间相同的名称空间：

var cc = new CustomizableControl();
var header = cc.GetXamlHeader();

Answer 3

我正在看这个，CustomizedObject 只是尖叫着要成为一个接口（并且由于每个具体类型都可以转换为对象，因此名称的这一部分是多余的）。您遇到的问题是，您不确定如何保留一些将被共享或仅因实现而略有不同的基本逻辑，并且您希望将此逻辑存储在树本身中，以便它可以多态地工作（是那一个词？）。

您可以通过代表来实现这一目标。我不确定到底是哪些成员给您带来了麻烦，但也许更像是这样的：

 ____________________________________      _____________________________________
| ICustomizable                      |    | System.Windows.Controls.UserControl |
|                                    |    |_____________________________________|
|   Func<string> XAMLHeader;         |                        ▲
|   Func<string> XAMLFooter          |◄--┐                    |
|   ICustomizabl LoadObject() |   \                    |
|   <Possible other implementations> |    \                   |
|____________________________________|     \                  |
         ▲                      ▲           \                 |
         |                      |            \                |
         |                      |             \               |
 _________________    ______________________   \    _____________________
| SpriteAnimation |  | SpriteAnimationFrame |  └---| CustomizableControl |
|_________________|  |______________________|      |_____________________|
                                                      ▲             ▲
                                                      |             |
                                                      |             |
                                                  ________    _____________
                                                 | Sprite |  | SpriteFrame |
                                                 |________|  |_____________|

此外，您可能有一些真正静态的逻辑，您觉得它们确实属于您的 CustomizedObject 类型。但这可能是错误的：您构建类型的目的是在特定情况下使用该类型。例如，从上下文来看，您似乎将创建这些控件和动画并在 Windows 窗体上使用它们。要做的事情是拥有从基本 System.Windows.Form 继承的自己的表单，并且这个新的表单类型应该了解 ICustomizedObject 以及如何使用它。这就是你的静态逻辑所在的地方。

这看起来有点尴尬，但当您决定更改演示引擎时，它被证明是准确的。如果将此代码移植到 WPF 或 Silverlight 会发生什么？他们可能需要使用与 Windows 窗体稍有不同的实现代码，并且您仍然可能需要更改 CustomizedControl 实现。但你的静态逻辑现在都在正确的位置。

最后，您使用的 LoadObject() 方法对我来说也很突出，因为它也出现在错误的位置。您是说您希望每个可自定义类型都提供一个可以调用的方法，该方法知道如何加载/构造自身。但这确实是不同的东西。您可能还需要另一个名为 IConstructable 的接口，并让您的 ICustomizable 类型实现该接口 (IConstructable)。

Answer 4

看来您必须求助于接口和对象组合。

Answer 5

在这种情况下我使用 mixin。 mixin 是一个强大的概念，在许多语言中使用，用于在运行时向类添加功能。 mixin 在许多语言中都是众所周知的。 re-mix框架是将mixin技术引入.NET的框架。

这个想法很简单：用代表 mixin 的类属性来装饰你的类。在运行时，此功能将添加到您的类中。所以你可以模拟多重继承。

问题的解决方案可能是将 CustomizedObject 制作为 mixin。为此，您将需要重新混合框架。

[使用（可定制对象混合）]
CustomizedControl ：用户控件

请查看 remix.codeplex.com 了解更多详细信息。

Answer 6

我认为这是解决方案之一。

public interface IClassA
{
    void Foo1();
    void Foo2();
}

public interface IClassB
{
    void Foo3();
    void Foo4();
}

public class ClassA :IClassA
{
    #region IClassA Members

    public void Foo1()
    {
    }

    public void Foo2()
    {
    }

    #endregion
}

public class ClassB :IClassB
{
    #region IClassB Members

    public void Foo3()
    {
    }

    public void Foo4()
    {
    }

    #endregion
}

public class MultipleInheritance :IClassA, IClassB
{
    private IClassA _classA;
    private IClassB _classB;

    public MultipleInheritance(IClassA classA, IClassB classB)
    {
        _classA = classA;
        _classB = classB;
    }

    public void Foo1()
    {
        _classA.Foo1();
    }

    public void Foo2()
    {
        _classA.Foo2();
        AddedBehavior1();
    }

    public void Foo3()
    {
        _classB.Foo3();
        AddedBehavior2();
    }

    public void Foo4()
    {
        _classB.Foo4();
    }

    private void AddedBehavior1()
    {

    }

    private void AddedBehavior2()
    {

    }
}

MultipleInheritance 类向两个不同的对象添加新行为，而不影响该对象的行为。 MultipleInheritance 与传递的对象具有相同的行为（继承两种行为）。