Страницы

Поиск по вопросам

воскресенье, 1 декабря 2019 г.

Почему в C# отказались от множественного наследования классов?

#c_sharp #множественное_наследование


Друзья, объясните или скиньте ссылки, где можно найти ответ на вопрос "Почему в 
C# отказались от множественного наследования классов ?"
    


Ответы

Ответ 1



TL;DR: добавление множественно наследования добавляет много сложностей, и мало выгоды от использования. перевод ответа Chris Brumme на вопрос Why doesn’t C# support multiple inheritance? Есть несколько причин почему мы не реализовали множественное наследование реализации напрямую. (Как вы знаете, мы поддерживаем множественное наследование интерфейсов). Однако, я должен обратить внимание на то, что компиляторы могут создавать множественное наследование для их типов внутри CLR. Есть несколько проблем, если идти этим путем: результат непроверяем, отсутствие взаимодействия с другими языками через CLS. Техника для создания некоторых VTables в RVA-шных статических полях. Для того, чтобы адреса управляемых методов (которые, возможно, даже не были обработаны JIT), вы используете конструкцию VTFixup. Эта конструкция представляет собой таблицу триплетов. Триплеты состоят из маркера на управляемый метод, адреса в вашем образе, который должен будет зафиксироваться (в этом случае, слот в VTable вы создаете в RVA-шных статических полях), и некоторых флагов. Возможные флаги описаны в corhdr.h. Они позволяют указать размер указателей: 32 бита vs 64 бита, контролировать виртуальное поведение, а также есть ли какой-нибудь режим обратного PInvoke, который следует применять в виде отложенных вычислений, что в итоге передаются в управляемый метод. Если мы выполняем переход unmanaged->managed, мы так же можем контролировать какой AppDomain будет выбран, чтобы отправить вызов. Есть несколько причин, почему мы не предоставили продуманную, поддающуюся проверке, CLS-совместимую версию множественного наследования реализации: Разные языки имеют разные ожидания того, как работает множественное наследование. Например, как решаются конфликты и будут ли дубликаты объединены или отброшены. Прежде чем мы сможем реализовать множественное наследование в CLR, мы должны сделать обзор всех языков, определить общие понятия, и решить как выразить их нейтральным способом. Мы должны решить будет ли множественное наследование входить в CLS и что это будет означать для языков, которые не хотят поддерживать эту концепцию (например VB.NET). Конечно это наше дело в CLR, но мы пока не нашли время сделать это для множественного наследования. Мест, где хорошо подходит множественное наследование, на самом деле очень мало. Во многих случаях работает множественное наследование интерфейсов. В других случаях можно использовать инкапсуляцию и делегирование. Если бы мы добавили другую конструкцию, например mixins, что было бы более мощным? Множественное наследование реализации добавляет сложности для реализации. Эта сложность влияет на кастинг, сериализацию, доступ к полям рефлексию и возможно многие другие места. Все еще не совсем ясно, что эта возможность окупит себя. Это то о чем мы часто спрашиваем себя. Это нечто, что мы еще не до конца проверили. Но мое нутро говорит, что после глубокого анализа мы решим не добавлять эту особенность.

Комментариев нет:

Отправить комментарий