Избыточны ли интерфейсы при множественном наследовании?

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

• Кшиштоф Квалина, в Язык программирования C # (4-е изд.) (стр.56)

Так что да, я считаю, что интерфейсы избыточны при множественном наследовании. Вы можете использовать чистые абстрактные базовые классы на языке, поддерживающем множественное наследование или смешивание.

Тем не менее, большую часть времени меня вполне устраивает одинарное наследование. Эрик Липперт ранее в том же томе (стр. 10) подчеркивает, что выбор единственного наследования «... устраняет одним махом многие сложные угловые случаи ...»

Нисколько. Интерфейсы определяют контракты без указания реализаций.

Таким образом, они необходимы, даже если присутствует множественное наследование - наследование касается реализации.

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

Зависит от теста на избыточность.

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

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

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

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

Существуют языки, поддерживающие множественное наследование, которые не включают концепцию параллельности интерфейсу Java. Эйфель - один из них. Бертран Мейер не видел в них необходимости, поскольку была возможность определить отложенный класс (который большинство людей называют абстрактным классом) с конкретным контрактом.

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

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

Таким образом, технически интерфейсы избыточны в языке, поддерживающем MI.

Но, как отмечали другие, множественное наследование может быть очень сложной задачей для правильного постоянного использования. Я знаю, что не смогу ... и я работал на Мейера, когда он занимался разработкой 2-го издания «Построение объектно-ориентированного программного обеспечения».

Являются ли интерфейсы в C # и Java лишь следствием того факта, что они не поддерживают множественное наследование?

Да, они. По крайней мере, на Яве. Создателям Java как простого языка был нужен язык, который большинство разработчиков могло бы понять без серьезной подготовки. С этой целью они работали над тем, чтобы сделать язык как можно более похожим на C ++ (знакомым), не перенося излишнюю сложность C ++ (простой). Разработчики Java решили разрешить множественное наследование интерфейсов с помощью интерфейсов, идея заимствована из протоколов Objective C. Подробности см. здесь

И, да, я считаю, что, как и в C ++, интерфейсы избыточны, если у вас множественное наследование. Если у вас есть более мощная функция, зачем оставлять меньше?

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

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

Фактически, если вы хотите запрограммировать Microsoft COM с помощью C, хотя C не знает концепции интерфейса, вы можете это сделать, потому что все файлы .h определяют интерфейсы следующим образом:

#if defined(__cplusplus) && !defined(CINTERFACE)
    MIDL_INTERFACE("ABCDE000-0000-0000-0000-000000000000")
    IMyInterface : public IUnknown
    {
   ...
    }
#else   /* C style interface */
    typedef struct IMyInterfaceVtbl
    {
        BEGIN_INTERFACE

        HRESULT ( STDMETHODCALLTYPE *SomMethod )(... ...);

        END_INTERFACE
    } IMyInterfaceVtbl;

    interface IMyInterface
    {
        CONST_VTBL struct IMyInterfaceVtbl *lpVtbl;
    };
#endif

Какой-то еще один синтаксический сахар ...

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

Интерфейсы предпочтительнее множественного наследования, поскольку наследование нарушает инкапсуляцию в соответствии с правилом 16 «Эффективная Java», Favor composition over inheritance.