он жеВ множественном наследовании нет полезности.
Никакой.

Это ерунда.

Просто в множественном наследовании, кроме полезности есть и дополнительная сложность, для грамотного управления которой требуется квалификация (прежде всего для того, чтобы понять, что наследованием пользоваться не нужно :)).
Как показывает практика, высокая квалификация не является нормой среди программистов, поэтому в языках нацеленых на массовое использование (java/c#) множественного наследования нет.
Ещё одной причиной отказа от множественного наследования является усложнение вычислительной модели языка. Чем эта модель проще, тем легче выполнять оптимизации при компиляции (в том числе и в JIT-компиляторах).

wnoise2NotGonnaGetUs : прошу прощения, а не подскажете, какая именно полезность от множественного наследования?

Польза от МН прежде всего практическая. Хотя через "объекты" можно выразить всё, что угодно (так же как при помощи лябда-исчисления чёрча или машины тьюринга), на практике это НЕ ВСЕГДА удобно. И становится ещё более не удобно, если отойти от теоретизирования и взяться за последовательную реализацию идей ООП в коде. В итоге в ОО-нотацию вторгаются генерики, ковариантность, вывод типов, замыкания (лямбды) и т.п.

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

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


Другая тема - моделирование "естественных" объектов или сложных математических структур данных.
Одно из обещаний ООП - простота повторного использования.
Однако реальная разработка классов для повторного использования упирается в ряд проблем.

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

Так происходит потому, что классификация понятий (в особенности естественных, таких как стол, машина и т.п.) не ограничивается только вариантом предложенным ещё аристотелем (когда принадлежность объекта к тому или иному классу определяется наличием или отсутствием у объекта определённых свойств) и успешно реализованным в оо-нотации статически типизированных языков. (Подчеркну: речь идёт только о лингвистических абстрациях заложенных в ОО языке, поскольку из того, что отсутствующую абстракцию можно _смоделировать_ не следует (а скорее следует обратное), что её можно будет продуктивно использовать (достаточно посмотреть как выглядит моделирование ООП в голом С или функции высших порядков в ОО языках)).

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

За иллюстрациями можно обратиться к главам посвящённым наследованию в книге Бертрана Мейера "Объектно-ориентированное конструирование программных систем ". Там разбирается каким образом МН можно использовать для представления различных классификаций одних и тех же объектов и ряд других интересных вопросов :)

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


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

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

bmv_rusА множественное наследование в природе сплош и рядом (мы же с вами от мамы И папы произошли а не от АбстастракХьюмена :) ).

Вот так, слово заслово, bmv_rus стал своим собственным папой, а заодно и мамой :)

Нет в природе никакого наследования. Особенно множественного. Всё у нас в голове. И не всегда то, что в ней находится, соответствует тому, что хотелось бы там иметь :)

[quot BlazkowiczТак тут смысл в том что в любой "ограниченой" системе множественное наследование можно применять сколько душе угодно. Проблемы начнутся когда эту систему нужно будет расширить. Тут-то м-наследование и станет поперек колес.[/quot]

Причём тут множественное наследование?

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

Если обратиться к вопросу наследования, то можно выделить порядка 12 типовых случаев, когда может применяться наследования: от различных классификаций объектов (наследование интерфейса) до самого хардкорного конструирования классов (наследование реализации).

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

Н-р, в java наследование реализованно в таком виде, что наследование properties от hashtable является дуростью.
В то время, как истинная дурость заключается в использовании делегирования для решения этой задачи, поскольку создаётся два объекта вместо одного (привет gc и оверхед на вложенные вызовы).

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

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