Multiple inheritance is one of those things that generally causes more problems than it solves. In C++ it fits the pattern of giving you enough rope to hang yourself, but Java and C# have chosen to go the safer route of not giving you the option. The biggest problem is what to do if you inherit multiple classes that have a method with the same signature that the inheritee doesn't implement. Which class's method should it choose? Or should that not compile? There is generally another way to implement most things that doesn't rely on multiple inheritance.

您可以有一个实现IFirst和ISecond的抽象基类，然后从该基类继承。

如果X继承了Y，这有两个正交的效果:

Y将为X提供默认功能，因此X的代码只需要包含与Y不同的东西。 几乎在任何需要用Y的地方，都可以用X代替。

Although inheritance provides for both features, it is not hard to imagine circumstances where either could be of use without the other. No .net language I know of has a direct way of implementing the first without the second, though one could obtain such functionality by defining a base class which is never used directly, and having one or more classes that inherit directly from it without adding anything new (such classes could share all their code, but would not be substitutable for each other). Any CLR-compliant language, however, will allow the use of interfaces which provide the second feature of interfaces (substitutability) without the first (member reuse).

由于多重继承(MI)的问题时常出现，我想添加一种方法来解决组合模式的一些问题。

我建立在IFirst, ISecond,First, Second, firststandsecond方法的基础上，就像问题中提到的那样。我将示例代码减少到IFirst，因为无论接口/ MI基类的数量如何，模式都保持不变。

让我们假设，MI First和MI Second都派生自同一个基类BaseClass，只使用BaseClass中的公共接口元素

这可以通过在第一个和第二个实现中向BaseClass添加容器引用来表示:

class First : IFirst {
  private BaseClass ContainerInstance;
  First(BaseClass container) { ContainerInstance = container; }
  public void FirstMethod() { Console.WriteLine("First"); ContainerInstance.DoStuff(); } 
}
...

当引用BaseClass中受保护的接口元素时，或者当First和Second是MI中的抽象类时，要求它们的子类实现一些抽象部分，事情就变得更加复杂了。

class BaseClass {
  protected void DoStuff();
}

abstract class First : IFirst {
  public void FirstMethod() { DoStuff(); DoSubClassStuff(); }
  protected abstract void DoStuff(); // base class reference in MI
  protected abstract void DoSubClassStuff(); // sub class responsibility
}

c#允许嵌套类访问其包含类的受保护/私有元素，因此这可以用于链接来自第一个实现的抽象位。

class FirstAndSecond : BaseClass, IFirst, ISecond {
  // link interface
  private class PartFirst : First {
    private FirstAndSecond ContainerInstance;
    public PartFirst(FirstAndSecond container) {
      ContainerInstance = container;
    }
    // forwarded references to emulate access as it would be with MI
    protected override void DoStuff() { ContainerInstance.DoStuff(); }
    protected override void DoSubClassStuff() { ContainerInstance.DoSubClassStuff(); }
  }
  private IFirst partFirstInstance; // composition object
  public FirstMethod() { partFirstInstance.FirstMethod(); } // forwarded implementation
  public FirstAndSecond() {
    partFirstInstance = new PartFirst(this); // composition in constructor
  }
  // same stuff for Second
  //...
  // implementation of DoSubClassStuff
  private void DoSubClassStuff() { Console.WriteLine("Private method accessed"); }
}

这里涉及到相当多的样板文件，但是如果FirstMethod和SecondMethod的实际实现足够复杂，并且访问的私有/受保护方法的数量适中，那么这种模式可能有助于克服缺乏多重继承的问题。

考虑只使用组合而不是尝试模拟多重继承。你可以使用接口来定义组成组合的类，例如:isteable暗示了方向盘类型的属性，IBrakable暗示了BrakePedal类型的属性，等等。

一旦你完成了这些，你可以使用c# 3.0中添加的扩展方法功能来进一步简化对这些隐含属性的方法调用，例如:

public interface ISteerable { SteeringWheel wheel { get; set; } }

public interface IBrakable { BrakePedal brake { get; set; } }

public class Vehicle : ISteerable, IBrakable
{
    public SteeringWheel wheel { get; set; }

    public BrakePedal brake { get; set; }

    public Vehicle() { wheel = new SteeringWheel(); brake = new BrakePedal(); }
}

public static class SteeringExtensions
{
    public static void SteerLeft(this ISteerable vehicle)
    {
        vehicle.wheel.SteerLeft();
    }
}

public static class BrakeExtensions
{
    public static void Stop(this IBrakable vehicle)
    {
        vehicle.brake.ApplyUntilStop();
    }
}


public class Main
{
    Vehicle myCar = new Vehicle();

    public void main()
    {
        myCar.SteerLeft();
        myCar.Stop();
    }
}

在我自己的实现中，我发现在MI中使用类/接口，虽然“形式很好”，但往往过于复杂，因为你需要为几个必要的函数调用设置所有的多重继承，在我的例子中，需要做几十倍的冗余。

相反，简单地在不同的模块化变体中创建静态的“调用调用函数的函数”作为一种面向对象的替代会更容易。我所致力于的解决方案是RPG的“法术系统”，即在不需要重新编写代码的情况下，效果需要大量混合和匹配函数调用来提供各种各样的法术，就像这个例子所表明的那样。

大多数函数现在都可以是静态的，因为我不必为拼写逻辑需要实例，而类继承在静态时甚至不能使用虚拟或抽象关键字。接口根本不能使用它们。

在我看来，这样编码更快更干净。如果只是使用函数，并且不需要继承属性，则使用函数。