Должен ли C# иметь множественное наследование?

Я ни разу не пропустил этого, никогда. Да, это [MI] становится сложным, и да, интерфейсы выполняют аналогичную работу во многих отношениях, но это не самое главное: в общем смысле в большинстве случаев это просто не нужно. Во многих случаях злоупотребляют даже одинарным наследованием.

Я думаю, что это слишком усложнит ситуацию без достаточной рентабельности инвестиций. Мы уже видим, как люди режут .NET-код слишком глубокими деревьями наследования. Я могу только представить себе зверства, если бы люди обладали способностью передавать множественное наследование.

Не стану отрицать, что у него есть потенциал, но я просто не вижу достаточной пользы.

C# поддерживает одиночное наследование, интерфейсы и методы расширения. Вместе они предоставляют практически все, что предоставляет множественное наследование, без головной боли, которую приносит множественное наследование.

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

Хотя, безусловно, есть примеры, когда это может быть полезно, я обнаружил, что в большинстве случаев, когда я думаю, что мне это нужно, на самом деле это не так.

Я работаю с C# с тех пор, как он был впервые доступен как альфа / бета-версия, и никогда не пропускал множественное наследование. MI хорош для некоторых вещей, но почти всегда есть другие способы достижения того же результата (некоторые из которых в конечном итоге оказываются проще или создают более понятную реализацию).

Предпочитайте агрегирование наследованию!

class foo : bar, baz

часто лучше справляется с

class foo : Ibarrable, Ibazzable
{
  ... 
  public Bar TheBar{ set }
  public Baz TheBaz{ set }

  public void BarFunction()
  {
     TheBar.doSomething();
  }
  public Thing BazFunction( object param )
  {
    return TheBaz.doSomethingComplex(param);
  }
}

Таким образом, вы можете менять местами различные реализации IBarrable и IBazzable для создания нескольких версий приложения без необходимости писать еще один класс.

Внедрение зависимостей может в этом сильно помочь.

Множественное наследование в целом может быть полезным, и многие языки объектно-ориентированного программирования так или иначе реализуют его (C++, Eiffel, CLOS, Python ...). Это важно? Нет. Это приятно иметь? да.

Обновлять
Я призываю всех, кто проголосует против меня, показать мне любой пример множественного наследования, которое я не могу легко перенести на язык с единичным наследованием. Если кто-то не может показать такой образец, я утверждаю, что его не существует. Я перенес тонны кода C++ (MH) на Java (без MH), и это никогда не было проблемой, независимо от того, сколько MH использовалось в коде C++.

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

На самом деле множественным наследованием обычно злоупотребляют. Если вы используете объектно-ориентированный дизайн, чтобы каким-то образом смоделировать реальный мир в классы, вы никогда не дойдете до точки, когда множественное наследование действительно имеет смысл. Можете ли вы привести полезный пример множественного наследования? Большинство примеров, которые я видел до сих пор, на самом деле «неправильные». Они делают что-то подклассом, который на самом деле является просто дополнительным свойством и, следовательно, интерфейсом.

Взгляните на Sather. Это язык программирования, где интерфейсы имеют множественное наследование, почему бы и нет (это не может создать проблему с ромбами), однако классы, которые не являются интерфейсами, не имеют никакого наследования. Они могут реализовывать только интерфейсы, и они могут «включать» другие объекты, что делает эти другие объекты их фиксированной частью, но это не то же самое, что наследование, это скорее форма делегирования (вызовы методов, «унаследованные» включением объектов, являются фактически просто пересылается экземплярам этих объектов, инкапсулированных в ваш объект). Я думаю, что эта концепция довольно интересна и показывает, что у вас может быть полностью чистый объектно-ориентированный язык без какого-либо наследования реализации.

Коллега написал в этом блоге о том, как получить что-то вроде множественного наследования в C# с помощью динамической компиляции:

http://www.atalasoft.com/cs/blogs/stevehawley/archive/2008/09/29/late-binding-in-c-using-dynamic-compilation.aspx

Нет.

(для голосования)

Я думаю, что это действительно просто. Как и любую другую сложную парадигму программирования, вы можете злоупотребить ею и навредить себе. Можете ли вы неправильно использовать объекты (о да!), Но это не значит, что объектно-ориентированный объект плох сам по себе.

Аналогично с МИ. Если у вас нет большого «дерева» унаследованных классов или большого количества классов, которые предоставляют методы с одинаковыми именами, тогда вам будет хорошо с MI. Фактически, поскольку MI предоставляет реализацию, вам часто будет лучше, чем реализация SI, где вам придется перекодировать или вырезать и вставить методы в делегированные объекты. В этих случаях лучше меньше кода. Вы можете создать беспорядок, разделяя код, пытаясь повторно использовать объекты через наследование интерфейса. И такие обходные пути плохо пахнут.

Я считаю, что модель .NET с единичным наследованием ошибочна: они должны были использовать только интерфейсы или только MI. Наличие «половины и половины» (т.е. наследования одной реализации плюс наследование множественных интерфейсов) сбивает с толку больше, чем должно быть, и совсем не элегантно.

Я происхожу из MI, и меня это не пугает и не обжигает.

Я размещал это здесь пару раз, но я просто думаю, что это действительно круто. Вы можете узнать, как подделать MI здесь. Я также думаю, что в статье подчеркивается, почему МИ - это такая боль, даже если это не было запланировано.

Я не скучаю по нему и не нуждаюсь в этом, я предпочитаю использовать композицию объектов для достижения своих целей. В этом и суть статьи.

Вот очень полезный случай множественного наследования, с которым я постоянно сталкиваюсь.

Как поставщик инструментария я не могу изменять опубликованные API, иначе я нарушу обратную совместимость. Одна вещь, которая возникает из этого, заключается в том, что я никогда не смогу добавить к интерфейсу после того, как я его выпустил, потому что это нарушит компиляцию для любого, кто его реализует - единственный вариант - расширить интерфейс.

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

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

Я бы предпочел использовать абстрактные классы, а затем, когда мне нужно добавить метод, добавить виртуальный с реализацией по умолчанию, и иногда мы делаем это.

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

Если мы думаем, что у нас есть эта проблема, мы вместо этого выбираем богатую модель событий - что, я думаю, вероятно, правильный ответ в C#, но не все проблемы решаются таким образом - иногда вам нужен простой общедоступный интерфейс , и более богатый для расширителей.

Я сам использовал множественное наследование в C++, но вам действительно нужно знать, что вы делаете, чтобы не попасть в беду, особенно если у вас есть два базовых класса, у которых есть общий дедушка или бабушка. Тогда вы можете столкнуться с проблемами виртуального наследования, когда вам придется объявлять каждый конструктор, который вы собираетесь вызывать по цепочке (что значительно усложняет повторное использование двоичного кода) ... это может будет беспорядком.

Что еще более важно, способ построения CLI в настоящее время не позволяет реализовать MI с легкостью. Я уверен, что они могли бы это сделать, если бы захотели, но у меня есть другие вещи, которые я бы предпочел увидеть в CLI, чем множественное наследование.

Вещи, которые я хотел бы видеть, включают некоторые функции Спецификация #, например ссылочные типы, не допускающие значения NULL. Я также хотел бы видеть больше безопасности объекта, имея возможность объявлять параметры как const и возможность объявлять функцию const (это означает, что вы гарантируете, что внутреннее состояние объекта не будет изменено методом и компилятор дважды проверяет вас).

Я думаю, что между одиночным наследованием, множественным наследованием интерфейсов, обобщениями и методами расширения вы можете делать практически все, что вам нужно. Если что-то может улучшить ситуацию для кого-то, кто желает MI, я думаю, нужна какая-то языковая конструкция, которая позволила бы упростить агрегирование и композицию. Таким образом, вы можете иметь общий интерфейс, но затем делегировать свою реализацию частному экземпляру класса, от которого вы обычно наследуете. Прямо сейчас для этого нужно много кода. Наличие более автоматизированной языковой функции для этого значительно поможет.

Множественное наследование не поддерживается CLR каким-либо образом, о котором я знаю, поэтому я сомневаюсь, что его можно поддерживать эффективным способом, как в C++ (или Eiffel, что может сделать это лучше, учитывая, что язык специально разработан. для меня).

Хорошая альтернатива множественному наследованию - Traits. Это позволяет вам смешивать различные единицы поведения в один класс. Компилятор может поддерживать признаки как расширение времени компиляции для системы типов с единичным наследованием. Вы просто объявляете, что класс X включает черты A, B и C, а компилятор объединяет запрошенные вами черты вместе, чтобы сформировать реализацию X.

Например, предположим, что вы пытаетесь реализовать IList (of T). Если вы посмотрите на разные реализации IList (of T), они часто используют один и тот же код. Вот и появились черты. Вы просто объявляете черту с общим кодом в ней, и вы можете использовать этот общий код в любой реализации IList (из T) - даже если в реализации уже есть какой-то другой базовый класс. Вот как может выглядеть синтаксис:

/// This trait declares default methods of IList<T>
public trait DefaultListMethods<T> : IList<T>
{
    // Methods without bodies must be implemented by another 
    // trait or by the class
    public void Insert(int index, T item);
    public void RemoveAt(int index);
    public T this[int index] { get; set; }
    public int Count { get; }

    public int IndexOf(T item)
    {
        EqualityComparer<T> comparer = EqualityComparer<T>.Default;
        for (int i = 0; i < Count; i++)
            if (comparer.Equals(this[i], item))
                return i;
        return -1;
    }
    public void Add(T item)
    {
        Insert(Count, item);
    }
    public void Clear()
    {   // Note: the class would be allowed to override the trait 
        // with a better implementation, or select an 
        // implementation from a different trait.
        for (int i = Count - 1; i >= 0; i--)
            RemoveAt(i);
    }
    public bool Contains(T item)
    {
        return IndexOf(item) != -1;
    }
    public void CopyTo(T[] array, int arrayIndex)
    {
        foreach (T item in this)
            array[arrayIndex++] = item;
    }
    public bool IsReadOnly
    {
        get { return false; }
    }
    public bool Remove(T item)
    {
        int i = IndexOf(item);
        if (i == -1)
            return false;
        RemoveAt(i);
        return true;
    }
    System.Collections.IEnumerator 
        System.Collections.IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
    IEnumerator<T> GetEnumerator()
    {
        for (int i = 0; i < Count; i++)
            yield return this[i];
    }
}

И вы используете эту черту так:

class MyList<T> : MyBaseClass, DefaultListMethods<T>
{
    public void Insert(int index, T item) { ... }
    public void RemoveAt(int index)       { ... }
    public T this[int index] {
        get { ... }
        set { ... }
    }
    public int Count {
        get { ... }
    }
}

Конечно, я здесь лишь поверхностно. Для более полного описания см. Статью Черты: составные единицы поведения (PDF).

В языке Rust (от Mozilla) трейты реализованы интересным образом: они заметили, что трейты похожи на реализации интерфейса по умолчанию, поэтому они объединили интерфейсы и трейты в одну функцию (которую они называют трейтами). Основное различие между типажами и реализациями интерфейса по умолчанию (которые сейчас есть в Java) состоит в том, что трейты могут содержать частные или защищенные методы, в отличие от традиционных методов интерфейса, которые должны быть общедоступными. Если черты и интерфейсы объединены в одну функцию нет, то еще одно отличие состоит в том, что вы можете иметь ссылку на интерфейс, но не можете иметь ссылку на черту; черта сама по себе не является типом.

Одной из проблем при работе с множественным наследованием является различие между наследованием интерфейса и наследованием реализации.

В C# уже есть чистая реализация наследования интерфейсов (включая выбор неявной или явной реализации) с использованием чистых интерфейсов.

Если вы посмотрите на C++, для каждого класса, который вы указываете после двоеточия в объявлении class, тип наследования, который вы получаете, определяется модификатором доступа (private, protected или public). С наследованием public вы получаете полную неразбериху множественного наследования - несколько интерфейсов смешиваются с несколькими реализациями. С наследованием private вы просто получаете реализацию. Объект «class Foo : private Bar» никогда не может быть передан функции, которая ожидает Bar, потому что это как если бы класс Foo действительно имел только частное поле Bar и автоматически реализуемый делегация шаблон.

Чистое наследование множественной реализации (которое на самом деле является просто автоматическим делегированием) не представляет никаких проблем, и было бы здорово иметь его на C#.

Что касается множественного наследования интерфейсов от классов, существует множество различных вариантов реализации этой функции. Каждый язык с множественным наследованием имеет свои собственные правила относительно того, что происходит, когда метод вызывается с тем же именем в нескольких базовых классах. Некоторые языки, такие как Common Lisp (особенно объектная система CLOS) и Python, имеют протокол метаобъектов, в котором вы можете указать приоритет базового класса.

Вот одна возможность:

abstract class Gun
{ 
    public void Shoot(object target) {} 
    public void Shoot() {}

    public abstract void Reload();

    public void Cock() { Console.Write("Gun cocked."); }
}

class Camera
{ 
    public void Shoot(object subject) {}

    public virtual void Reload() {}

    public virtual void Focus() {}
}

//this is great for taking pictures of targets!
class PhotoPistol : Gun, Camera
{ 
    public override void Reload() { Console.Write("Gun reloaded."); }

    public override void Camera.Reload() { Console.Write("Camera reloaded."); }

    public override void Focus() {}
}

var    pp      = new PhotoPistol();
Gun    gun     = pp;
Camera camera  = pp;

pp.Shoot();                    //Gun.Shoot()
pp.Reload();                   //writes "Gun reloaded"
camera.Reload();               //writes "Camera reloaded"
pp.Cock();                     //writes "Gun cocked."
camera.Cock();                 //error: Camera.Cock() not found
((PhotoPistol) camera).Cock(); //writes "Gun cocked."
camera.Shoot();                //error:  Camera.Shoot() not found
((PhotoPistol) camera).Shoot();//Gun.Shoot()
pp.Shoot(target);              //Gun.Shoot(target)
camera.Shoot(target);          //Camera.Shoot(target)

В этом случае в случае конфликта неявно наследуется только реализация первого из перечисленных классов. Класс для других базовых типов должен быть явно указан, чтобы получить доступ к их реализациям. Чтобы сделать его более защищенным от идиотов, компилятор может запретить неявное наследование в случае конфликта (конфликтующие методы всегда требуют преобразования).

Кроме того, вы можете реализовать множественное наследование в C# сегодня с помощью операторов неявного преобразования:

public class PhotoPistol : Gun /* ,Camera */
{
    PhotoPistolCamera camera;

    public PhotoPistol() {
        camera = new PhotoPistolCamera();
    }

    public void Focus() { camera.Focus(); }

    class PhotoPistolCamera : Camera 
    { 
        public override Focus() { }
    }

    public static Camera implicit operator(PhotoPistol p) 
    { 
        return p.camera; 
    }
}

Однако он не идеален, поскольку не поддерживается операторами is и as, а также System.Type.IsSubClassOf().

Нет, мы ушли от этого. Вам это нужно сейчас.

Я предпочитаю C++. Я использовал Java, C# и т. д. По мере того, как мои программы становятся более сложными в такой объектно-ориентированной среде, мне не хватает множественного наследования. Это мой субъективный опыт.

Он может создать потрясающий спагетти-код ... он может создать удивительно элегантный код.

Интерфейсы имеют множественное наследование. Фактически, я бы считал интерфейсы типов Java / C# «правильной» реализацией множественного наследования. Принудительное множественное наследование с использованием интерфейсов вместо разрешения наследования от нескольких конкретных или абстрактных классов вынуждает разработчика использовать композицию / делегирование для повторного использования кода. Наследование никогда не должно использоваться для повторного использования кода, а отсутствие множественного наследования типов C++ вынуждает разработчиков придумывать лучше спроектированные классы.

Я рад, что в C# нет множественного наследования, хотя иногда это было бы удобно. Вместо этого я хотел бы видеть возможность предоставить реализацию метода интерфейса по умолчанию. То есть:

interface I
{
    void F();
    void G();
}


class DefaultI : I
{
    void F() { ... }
    void G() { ... }
}

class C : I = DefaultI
{
    public void F() { ... } // implements I.F
}

В этом случае ((I)new C()).F() вызовет реализацию C для I.F(), а ((I)new C()).G() вызовет реализацию DefaultI для I.G().

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

одной из действительно хороших и (в то время) новинок в DataFlex 4GL v3 + (я знаю, знаю, Data какие?) была поддержка наследования миксин - методы из любых других классов можно было повторно использовать в вашем классе; до тех пор, пока ваш класс предоставил свойства, которые использовали эти методы, он работал нормально, и не было «проблем с ромбами» или других «подводных камней», о которых нужно было беспокоиться.

я хотел бы видеть что-то подобное в C#, так как это упростило бы определенные виды абстракции и проблем конструкции.

На самом деле я пропускаю множественное наследование по одной конкретной причине ... шаблон удаления.

КАЖДЫЙ раз, когда мне нужно реализовать шаблон удаления, я говорю себе: «Хотел бы я просто унаследовать от класса, который реализует шаблон удаления с несколькими виртуальными переопределениями». Я копирую и вставляю один и тот же шаблонный код в каждый класс, реализующий IDispose, и мне это не нравится.

Я считаю, что такие языки, как C#, должны давать программисту возможность. Тот факт, что может быть слишком сложен, не означает, что будет слишком сложен. Языки программирования должны предоставлять разработчику инструменты для создания всего, что пожелает программист.

Вы решаете использовать те API, которые уже написал разработчик, но у вас их тоже нет.

ДА! ДА! и да!

Серьезно, я всю свою карьеру занимался разработкой GUI-библиотек, и MI (множественное наследование) делает это намного проще, чем SI (одиночное наследование).

Сначала я сделал SmartWin ++ на C++ (интенсивно использовался MI), затем я сделал Gaia Ajax и, наконец, теперь Ра-Аякс, и я могу с крайней уверенностью заявить, что MI для некоторых мест управляет. Одно из таких мест - библиотеки графического интерфейса ...

И аргументы, утверждающие, что МИ «слишком сложен» и так далее, в основном выдвигаются людьми, пытающимися построить языковые войны, и принадлежат к лагерю, у которого «в настоящее время нет МИ» ...

Точно так же, как языки функционального программирования (например, Lisp) преподавались («не-Lispers») как «слишком сложные» сторонники нефункционального языка программирования ...

Люди боятся неизвестного ...

МИ ПРАВИЛА!

Дайте C# подразумевает, и вы не пропустите множественное наследование или какое-либо наследование в этом отношении.

Нет, я не. Я использую все другие функции объектно-ориентированного проектирования для разработки того, что хочу Я использую инкапсуляцию интерфейса и объектов, и я никогда не ограничен в том, что хочу делать.

Я стараюсь не использовать наследование. Тем меньше я могу каждый раз.

Вместо множественного наследования вы можете использовать миксины, что является лучшим решением.

Если мы введем множественное наследование, мы снова столкнемся со старой проблемой Diamond C++ ...

Однако для тех, кто считает это неизбежным, мы все же можем ввести множественные эффекты наследования посредством композиции (составить несколько объектов в объекте и предоставить общедоступные методы, которые делегируют ответственность составному объекту и возвращают) ...

Так зачем беспокоиться о множественном наследовании и делать свой код уязвимым для неизбежных исключений ...

Я почти не скучаю по множественному наследованию в C#.

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

Большинство мест, где множественное наследование имеет реальную ценность, - это места, где речь идет не о самом домене, а о некоторых ограничениях технологии / фреймворка, которые требуют от вас использования MI. Реализация COM-объектов с использованием ATL - очень хороший пример использования множественного наследования для реализации всех необходимых интерфейсов, необходимых COM-объекту, и элегантное решение уродливой (по сравнению с .NET) технологии. Элегантно с точки зрения того, что это фреймворк C++!

Однако сейчас у меня возникла ситуация, когда я мог бы использовать множественное наследование. У меня есть один класс, который должен наследовать функции от другого объекта домена, но он также должен быть доступен для вызовов между доменами приложений. Это означает, что он ДОЛЖЕН наследоваться от MarshalByRefObject. Итак, в этом конкретном случае я действительно хотел бы получить как от MarshalByRefObject, так и от моего конкретного объекта домена. Однако это невозможно, поэтому мой класс должен реализовать тот же интерфейс, что и мой объект домена, и переадресовывать вызовы агрегированному экземпляру.

Но это, как я уже сказал, тот случай, когда технология / фреймворк накладывает ограничение, а не сама модель предметной области.

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

P / S Вы «редко» избегаете крайне необходимого программного решения только потому, что оно сложно. «Сложность» не оправдывает отсутствие множественного наследования. Многопоточность сложна, но она доступна на C#. Большая проблема отсутствия множественного наследования связана с проблемой ромба (http://en.wikipedia.org/wiki/Diamond_problem). К вашему комментарию о лучших альтернативах применимы хитрые рассуждения (люди решают и думают по-разному, поэтому иногда одно решение - плохая идея) и подходящие варианты уже существуют (зачем создавать LINQ, когда ADO.NET делает свое дело и является зрелым ... из-за к силе одного над другим.)

Нет, если проблема с бриллиантом не будет решена. и вы можете использовать композицию, пока она не будет решена.

Было бы проще, меньше кода, если бы интерфейсы могли иметь реализацию. Но могут ли они быть использованы не по назначению, а не по назначению? Я думаю, что, пока вы не увидите, как это можно сделать должным образом, вы не упустите это. Меня раздражают аргументы, что множественное наследование небезопасно. Это не. Но почти все языковые реализации есть. Но НУЖНО ли оно нам? Я не знаю.

Я бы предпочел ковариацию возвращаемого типа, это можно легко добавить (просто ослабьте правила для типа возвращаемого значения в замещенных методах), и это всегда безопасно.

пример:

class shape {}

class circle : shape {}

interface part {
    shape Form();
}

interface wheel : part {
    circle Form();
}