Множественное наследование - зло?
Possible Duplicate:
What is the exact problem with multiple inheritance?
Почему множественное наследование считается зло, а реализация нескольких интерфейсов - нет? Особенно если учесть, что интерфейсы - это просто чистые абстрактные классы?
(Более или менее) дубликатВ чем именно заключается проблема множественного наследования?, Множественное наследование в C# и некоторые другие ...
Ответы 4
Как вы согласовываете, реализует ли A метод с именем z, а b реализует метод с именем z, и у вас есть:
ребенок: а, б
теперь, если мой клиентский код вызывает new child (). z (). Какая реализация вызывается? Я не думаю, что это так сильно, как то, что его зло просто поднимает много проблем и мало ценится.
Распространенной проблемой множественного наследования является «проблема ромба».
A
/ \
B c
\ /
D
Если виртуальный метод в A реализуется как B, так и C, какой из них вы получите при создании D?
Причина, по которой это не проблема с интерфейсами, заключается в том, что интерфейсы не имеют реализаций, поэтому, если A / B / C - все интерфейсы, тогда D выбирает, как реализовать методы A любым подходящим способом.
Это не проблема, если вы требуете от D двусмысленности.
МИ - это не столько зло, сколько очень сложное решение редкой проблемы. В большинстве случаев есть лучший способ сделать то же самое.
Это воспринимается как зло, потому что это просто более сложно и вызывает больше проблем, чем люди обычно ожидают, особенно когда базовые классы не являются чисто абстрактными (без элементов данных). Алмазное наследование может быть решено с помощью виртуального наследования, когда общая база является общей. А компиляторы могут улавливать конфликты сигнатур методов. При правильном использовании он может создавать элегантные и СУХИЕ решения, которые в противном случае более подробны для реализации через интерфейс и композиции / делегирование.
Одна из распространенных идиом MI в C++ - для сложных конструкторов-оболочек, где базовый конструктор должен быть сконструирован с нетривиальными объектами-членами, а поскольку базовые объекты должны быть созданы перед объектами-членами, трюк заключается в использовании MI («основание из члена» idiom.), в противном случае вам придется использовать фабрику и дополнительные шаги для создания конструкции, как это делает Java (Java не имеет MI для классов, не являющихся интерфейсами).
Не бойтесь этого и используйте его, когда это уместно (хотя может потребоваться некоторая практика, чтобы найти подходящий вариант).
Эта проблема может быть легко решена, если компилятор потребует от вас переопределить метод z в дочернем классе. Кроме того, такая же проблема возникает в языках, где разрешено множественное наследование интерфейсов, если у вас есть 2 интерфейса с методом с тем же именем, но с другой подписью.