由于多重继承是不好的(它使源代码更加复杂)，c#没有直接提供这样的模式。但有时候拥有这种能力是有帮助的。

c#和。net CLR还没有实现MI，因为他们还没有总结出它将如何在c#、VB.net和其他语言之间互操作，而不是因为“这会使源代码更复杂”。

MI是一个有用的概念，未回答的问题是:“当你在不同的超类中有多个公共基类时，你该怎么办?”

Perl是我使用过的唯一一种MI可以很好地工作的语言。. net可能有一天会引入它，但现在还没有，CLR已经支持MI，但正如我所说的，目前还没有针对它的语言结构。

在此之前，你会被代理对象和多个接口所困扰:(

由于多重继承是不好的(它使源代码更加复杂)，c#没有直接提供这样的模式。但有时候拥有这种能力是有帮助的。

c#和。net CLR还没有实现MI，因为他们还没有总结出它将如何在c#、VB.net和其他语言之间互操作，而不是因为“这会使源代码更复杂”。

MI是一个有用的概念，未回答的问题是:“当你在不同的超类中有多个公共基类时，你该怎么办?”

Perl是我使用过的唯一一种MI可以很好地工作的语言。. net可能有一天会引入它，但现在还没有，CLR已经支持MI，但正如我所说的，目前还没有针对它的语言结构。

在此之前，你会被代理对象和多个接口所困扰:(

是的，使用接口是一个麻烦，因为每当我们在类中添加方法时，我们都必须在接口中添加签名。此外，如果我们已经有一个类有一堆方法，但没有接口怎么办?我们必须手动为所有想要继承的类创建Interface。最糟糕的是，如果子类要从多个接口继承，我们必须在子类中实现接口中的所有方法。

通过遵循Facade设计模式，我们可以使用访问器模拟从多个类继承。在类内部使用{get;set;}将类声明为需要继承的属性，所有公共属性和方法都来自该类，并在子类的构造函数中实例化父类。

例如:

 namespace OOP
 {
     class Program
     {
         static void Main(string[] args)
         {
             Child somechild = new Child();
             somechild.DoHomeWork();
             somechild.CheckingAround();
             Console.ReadLine();
         }
     }

     public class Father 
     {
         public Father() { }
         public void Work()
         {
             Console.WriteLine("working...");
         }
         public void Moonlight()
         {
             Console.WriteLine("moonlighting...");
         }
     }


     public class Mother 
     {
         public Mother() { }
         public void Cook()
         {
             Console.WriteLine("cooking...");
         }
         public void Clean()
         {
             Console.WriteLine("cleaning...");
         }
     }


     public class Child 
     {
         public Father MyFather { get; set; }
         public Mother MyMother { get; set; }

         public Child()
         {
             MyFather = new Father();
             MyMother = new Mother();
         }

         public void GoToSchool()
         {
             Console.WriteLine("go to school...");
         }
         public void DoHomeWork()
         {
             Console.WriteLine("doing homework...");
         }
         public void CheckingAround()
         {
             MyFather.Work();
             MyMother.Cook();
         }
     }


 }

有了这个结构，类Child可以访问父类和母类的所有方法和属性，模拟多重继承，继承父类的实例。不完全一样，但很实用。

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

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

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

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

如果你可以接受IFirst和ISecond的方法只能与IFirst和ISecond的契约交互的限制(就像你的例子一样)……你可以用扩展方法做你想做的事情。在实践中，这种情况很少发生。

public interface IFirst {}
public interface ISecond {}

public class FirstAndSecond : IFirst, ISecond
{
}

public static MultipleInheritenceExtensions
{
  public static void First(this IFirst theFirst)
  {
    Console.WriteLine("First");
  }

  public static void Second(this ISecond theSecond)
  {
    Console.WriteLine("Second");
  }
}

///

public void Test()
{
  FirstAndSecond fas = new FirstAndSecond();
  fas.First();
  fas.Second();
}

因此，基本思想是在接口中定义所需的实现……这个需要的东西应该支持扩展方法中的灵活实现。当你需要“向接口添加方法”时，你可以添加一个扩展方法。

这与Lawrence Wenham的回答相似，但取决于您的用例，这可能是一种改进，也可能不是——您不需要setter。

public interface IPerson {
  int GetAge();
  string GetName();
}

public interface IGetPerson {
  IPerson GetPerson();
}

public static class IGetPersonAdditions {
  public static int GetAgeViaPerson(this IGetPerson getPerson) { // I prefer to have the "ViaPerson" in the name in case the object has another Age property.
    IPerson person = getPerson.GetPersion();
    return person.GetAge();
  }
  public static string GetNameViaPerson(this IGetPerson getPerson) {
    return getPerson.GetPerson().GetName();
  }
}

public class Person: IPerson, IGetPerson {
  private int Age {get;set;}
  private string Name {get;set;}
  public IPerson GetPerson() {
    return this;
  }
  public int GetAge() {  return Age; }
  public string GetName() { return Name; }
}

现在，任何知道如何获取一个人的对象都可以实现IGetPerson，并且它将自动拥有GetAgeViaPerson()和GetNameViaPerson()方法。从这一点开始，基本上所有的Person代码都进入IGetPerson，而不是IPerson，除了新的ivars，它必须同时进入IGetPerson和IPerson。在使用这样的代码时，你不需要关心你的IGetPerson对象本身是不是一个IPerson。