почему vb.net не поддерживает множественное наследование?

Question

Я видел некоторые дискуссии о том, почему c # не реализует множественное наследование, но очень мало о том, почему он не поддерживается в vb. Я понимаю, что и c #, и vb компилируются до языка-посредника, и поэтому им обоим необходимо иметь одинаковые ограничения.

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

Answer 1

Он не реализован в CLR, поэтому он не доступен в CLS-совместимых языках, таких как VB.NET. Похоже, что среди инженеров Microsoft, в том числе Андерса Хейлсберга, ведущего архитектора C #, существует общее мнение о том, что потенциальные выгоды не стоят затрат и сложности внедрения. Крис Брамм, выдающийся инженер команды .NET в то время, сказал это еще в 2004 году:

Существует несколько причин, по которым мы не предоставили запечатанную, проверяемую CLS-совместимую версию наследования нескольких реализаций:

1. У разных языков разные ожидания относительно того, как работает MI. Например, как разрешаются конфликты и объединяются или дублируются дублирующие базы. Прежде чем мы сможем внедрить MI в CLR, мы должны сделать обзор всех языков, выяснить общие понятия и решить, как выразить их нейтральным языком. Мы также должны были бы решить, принадлежит ли MI в CLS и что это будет означать для языков, которые не хотят этого понятия (например, VB.NET, например). Конечно, это бизнес, которым мы занимаемся в качестве общеязыковой среды выполнения, но мы пока не успели сделать это для MI.

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

3. Множественное наследование реализации вносит большую сложность в реализацию. Эта сложность влияет на приведение, компоновку, отправку, доступ к полям, сериализацию, сравнение идентификаторов, проверяемость, рефлексию, обобщение и, возможно, множество других мест.

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

[ Ссылка ]

Суть в том, что я не задерживаю дыхание.

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

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

Answer 2

Все языки dotNET используют общую систему типов, и этот CTS не поддерживает множественное наследование. Определенный язык, такой как VB или C #, не может добавить это сам по себе, он станет несовместимым с остальной частью dotNET. Самое большее, что язык может выбрать, чтобы игнорировать / скрыть такую ​​функцию.

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

Answer 3

Отсутствие MI (множественного наследования) сильно связано как с языком, так и с предполагаемым хостом (CLR):

1) Разница в MI / SI настолько фундаментальна для языка, что позже очень трудно (или, возможно, невозможно) «добавить его как функцию».

2) Что касается предполагаемого хоста: в то время как будет возможным написать язык MI для CLR (точно так же, как можно было бы написать язык с продолжениями и т. Д. Для CLR - - это может быть сделано), что при этом вы теряете совместимость со всеми остальными языками .NET.

Гораздо более простой формой «MI», которую можно установить в CLR, являются черты, обрабатываемые посредством коллапса MRO во время компиляции (именно так Scala поддерживает черты в JVM). Тем не менее, это все еще требует Major редизайн / переосмысление языка, и для чего-то такого же «проверенного», как VB (.NET), удачи :-) Необходимо убедиться, что он хорошо работает с существующим кодом большое дело при добавлении улучшений в язык.

Answer 4

Предположим, у типа B есть виртуальный метод m, типы которого X и Y реализуют по-разному, хотя обе реализации объединяются в цепочку base.m(), D, полученную из X и Y без определения его собственная реализация, и George является экземпляром D. Класс X будет ожидать, что ни один производный класс не получит доступ к B.m() без прохождения собственной реализации этого метода, а класс Y будет иметь аналогичное ожидание. CType(George,B).m() ничего не может сделать компилятор, который не нарушил бы такие ожидания. Если для прохождения типа X или Y требовалось повысить рейтинг от D до B, то приведение, прошедшее через X, могло бы использовать метод X и приведение, прошедшее Y может использовать метод Y, но ссылка на D не будет напрямую использоваться кодом, который ожидает ссылку на B (или, в этом отношении, Object). Требование, чтобы только интерфейсы могли наследоваться множественным образом, и что каждый тип, который реализует интерфейс, должен обеспечивать реализации всех методов, почти так же хорош, как и обеспечение обобщенного множественного наследования, но не вызывает тех же неоднозначностей.

Answer 5

Почему C # или VB.NET не поддерживают множественное наследование

http://royalarun.blogspot.in/2013/05/why-c-or-vbnet-doesnt-support-multiple.html

1) Первая причина - двусмысленность вокруг проблемы Diamond, рассмотрим, что класс A имеет метод foo (), а затем B и C получены из A и имеют собственную реализацию foo (), а теперь класс D наследуется от B и C с использованием множественного наследования. и если мы ссылаемся только на foo (), компилятор не сможет решить, какой foo () он должен вызывать. Это также называется проблемой с бриллиантами, поскольку структура в этом сценарии наследования аналогична 4-гранному бриллианту, см. Ниже

      A foo()
       / \
      /   \  
foo() B     C foo()  
      \   /  
       \ /  
        D
       foo()

По моему мнению, даже если мы удалим верхнюю головку алмаза класса A и допустим множественное наследование, мы увидим эту проблему двусмысленности.

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

2) Вторая и более убедительная причина для меня заключается в том, что множественное наследование усложняет проектирование и создает проблемы во время приведения, построения конструктора и т. Д., И, учитывая, что существует не так много сценариев, для которых вам нужно множественное наследование, его мудрое решение не использовать его для ради простоты. Также c # и избегает этой неоднозначности, поддерживая одиночное наследование с интерфейсами. Поскольку интерфейс имеет только объявление метода и не обеспечивает никакой реализации, будет только одна реализация конкретного метода, следовательно, не будет никакой двусмысленности.

Answer 6

Существует много других техник, которые значительно превосходят MI, например, композиция. Даже в таких языках, как C ++, которые поддерживают MI, очень редко можно увидеть, как класс наследуется от двух неабстрактных базовых классов.