Множественное наследование в C #

Поскольку множественное наследование - это плохо (оно усложняет исходный код), C # не предоставляет такой шаблон напрямую. Но иногда было бы полезно иметь эту способность.

C # и .net CLR не реализовали MI, потому что они еще не пришли к выводу, как он будет взаимодействовать между C #, VB.net и другими языками, а не потому, что «это сделало бы исходный код более сложным»

MI - полезная концепция, вопросы без ответа такие, как: - «Что вы делаете, когда у вас есть несколько общих базовых классов в разных суперклассах?

Perl - единственный язык, с которым я когда-либо работал, где MI работает и работает хорошо. .Net вполне может представить его однажды, но пока нет, CLR уже поддерживает MI, но, как я уже сказал, для него еще нет языковых конструкций.

До тех пор вместо этого вы застряли с прокси-объектами и несколькими интерфейсами :(

Рассмотрите возможность использования композиции вместо попытки имитировать множественное наследование. Вы можете использовать интерфейсы, чтобы определить, какие классы составляют композицию, например: ISteerable подразумевает свойство типа SteeringWheel, 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();
    }
}

Я создал пост-компилятор C #, который позволяет делать такие вещи:

using NRoles;

public interface IFirst { void FirstMethod(); }
public interface ISecond { void SecondMethod(); }

public class RFirst : IFirst, Role {
  public void FirstMethod() { Console.WriteLine("First"); }
}

public class RSecond : ISecond, Role {
  public void SecondMethod() { Console.WriteLine("Second"); }
}

public class FirstAndSecond : Does<RFirst>, Does<RSecond> { }

Вы можете запустить посткомпилятор как событие после сборки Visual Studio:

C: \ some_path \ nroles-v0.1.0-bin \ nutate.exe "$ (TargetPath)"

В той же сборке вы используете это так:

var fas = new FirstAndSecond();
fas.As<RFirst>().FirstMethod();
fas.As<RSecond>().SecondMethod();

В другой сборке вы используете это так:

var fas = new FirstAndSecond();
fas.FirstMethod();
fas.SecondMethod();

У вас может быть один абстрактный базовый класс, который реализует как IFirst, так и ISecond, а затем наследовать только от этой базы.

С C # 8 теперь у вас практически есть множественное наследование через реализацию членов интерфейса по умолчанию:

interface ILogger
{
    void Log(LogLevel level, string message);
    void Log(Exception ex) => Log(LogLevel.Error, ex.ToString()); // New overload
}

class ConsoleLogger : ILogger
{
    public void Log(LogLevel level, string message) { ... }
    // Log(Exception) gets default implementation
}

Мы все, кажется, идем по пути интерфейса с этим, но очевидная другая возможность здесь - сделать то, что должно делать ООП, и построить свое дерево наследования ... (разве это не какой класс дизайн - это все?)

class Program
{
    static void Main(string[] args)
    {
        human me = new human();
        me.legs = 2;
        me.lfType = "Human";
        me.name = "Paul";
        Console.WriteLine(me.name);
    }
}

public abstract class lifeform
{
    public string lfType { get; set; }
}

public abstract class mammal : lifeform 
{
    public int legs { get; set; }
}

public class human : mammal
{
    public string name { get; set; }
}

Эта структура предоставляет повторно используемые блоки кода и, конечно же, как следует писать код ООП?

Если этот конкретный подход не совсем соответствует требованиям, мы просто создаем новые классы на основе требуемых объектов ...

class Program
{
    static void Main(string[] args)
    {
        fish shark = new fish();
        shark.size = "large";
        shark.lfType = "Fish";
        shark.name = "Jaws";
        Console.WriteLine(shark.name);
        human me = new human();
        me.legs = 2;
        me.lfType = "Human";
        me.name = "Paul";
        Console.WriteLine(me.name);
    }
}

public abstract class lifeform
{
    public string lfType { get; set; }
}

public abstract class mammal : lifeform 
{
    public int legs { get; set; }
}

public class human : mammal
{
    public string name { get; set; }
}

public class aquatic : lifeform
{
    public string size { get; set; }
}

public class fish : aquatic
{
    public string name { get; set; }
}

В моей собственной реализации я обнаружил, что использование классов / интерфейсов для MI, хотя и является «хорошей формой», как правило, было чрезмерно сложным, поскольку вам нужно настроить все это множественное наследование только для нескольких необходимых вызовов функций, и в моем случае нужно было делать буквально десятки раз с дублированием.

Вместо этого было проще создать статические «функции, вызывающие функции, вызывающие функции» в различных модульных вариантах в качестве своего рода замены ООП. Решением, над которым я работал, была «система заклинаний» для ролевой игры, в которой эффекты необходимо сильно смешивать и согласовывать, вызывая функцию, чтобы дать огромное разнообразие заклинаний без переписывания кода, как и в случае с пример, кажется, указывает.

Большинство функций теперь могут быть статическими, потому что мне не обязательно нужен экземпляр для логики заклинаний, тогда как наследование классов не может даже использовать виртуальные или абстрактные ключевые слова в статике. Интерфейсы вообще не могут их использовать.

Кодирование кажется намного быстрее и чище, IMO. Если вы просто выполняете функции и не нуждаетесь в унаследованных свойствах, используйте functions.

Если вы можете жить с ограничением, что методы 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();
}

Итак, основная идея состоит в том, что вы определяете требуемую реализацию в интерфейсах ... этот требуемый материал должен поддерживать гибкую реализацию в методах расширения. Каждый раз, когда вам нужно «добавить методы к интерфейсу», вместо этого вы добавляете метод расширения.

Да, использование интерфейса - это проблема, потому что каждый раз, когда мы добавляем метод в класс, мы должны добавить подпись в интерфейс. Кроме того, что, если у нас уже есть класс с кучей методов, но без интерфейса для него? нам нужно вручную создать интерфейс для всех классов, от которых мы хотим унаследоваться. И хуже всего то, что мы должны реализовать все методы в интерфейсах в дочернем классе, если дочерний класс должен унаследовать от множественного интерфейса.

Следуя шаблону проектирования фасада, мы можем имитировать наследование от нескольких классов с помощью средств доступа. Объявите классы как свойства с помощью {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 будет иметь доступ ко всем методам и свойствам классов Отец и Мать, моделируя множественное наследование, наследуя экземпляр родительских классов. Не совсем то же самое, но практично.

Это похоже на ответ Лоуренса Уэнама, но в зависимости от вашего варианта использования это может быть или не быть улучшением - вам не нужны сеттеры.

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.

Множественное наследование - одна из тех вещей, которые обычно вызывают больше проблем, чем решают. В C ++ это соответствует схеме, когда вам дают достаточно веревки, чтобы повеситься, но Java и C # выбрали более безопасный путь, не давая вам такой возможности. Самая большая проблема заключается в том, что делать, если вы наследуете несколько классов, у которых есть метод с той же сигнатурой, которую наследник не реализует. Какой метод класса следует выбрать? Или это не должно компилироваться? Как правило, существует другой способ реализовать большинство вещей, не основанный на множественном наследовании.

Если X наследуется от Y, это имеет два несколько ортогональных эффекта:

1. Y will provide default functionality for X, so the code for X only has to include stuff which is different from Y.
2. Almost anyplace a Y would be expected, an X may be used instead.

Хотя наследование обеспечивает обе функции, нетрудно представить себе обстоятельства, при которых одна из них может быть полезной без другой. Ни один язык .net, о котором я знаю, не имеет прямого способа реализации первого без второго, хотя можно получить такую ​​функциональность, определив базовый класс, который никогда не используется напрямую, и имея один или несколько классов, которые наследуются напрямую от него, не добавляя ничего new (такие классы могут иметь общий код, но не могут быть заменены друг на друга). Однако любой CLR-совместимый язык позволит использовать интерфейсы, которые обеспечивают вторую функцию интерфейсов (заменяемость) без первой (повторное использование членов).

Я знаю, что знаю, хотя это запрещено и так далее, иногда вам это действительно нужно, поэтому для тех:

class a {}
class b : a {}
class c : b {}

как и в моем случае, я хотел сделать этот класс b: Form (да, windows.forms) class c: b {}

Потому что половина функции была идентична, и с интерфейсом вы должны переписать их все

Поскольку вопрос о множественном наследовании (MI) возникает время от времени, я хотел бы добавить подход, который решает некоторые проблемы с шаблоном композиции.

Я основываюсь на подходе IFirst, _2 _, _ 3_, Second, FirstAndSecond, как он был представлен в вопросе. Я сокращаю образец кода до IFirst, поскольку шаблон остается неизменным независимо от количества интерфейсов / базовых классов MI.

Предположим, что с MI First и Second будут производными от одного и того же базового класса BaseClass, используя только элементы общедоступного интерфейса из BaseClass

Это можно выразить, добавив ссылку на контейнер на BaseClass в реализации First и Second:

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 # позволяет вложенным классам получать доступ к защищенным / частным элементам содержащих их классов, поэтому это можно использовать для связывания абстрактных битов из реализации First.

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 достаточно сложна и количество доступных частных / защищенных методов умеренное, то этот шаблон может помочь преодолеть отсутствие множественного наследования.