Обсуждение:Множественное наследование

МН в ФП

• Множественное наследование классов поддерживают и языки функционального программирования, например Haskell. ESSch 21:31, 31 мая 2010 (UTC)
  • Статья начинается с перечисления ряда известных языков с множественном наследованием; в том числе указаны функциональные языки Common Lisp и OCaml. Но Haskell в этот список я бы включать не стал т.к. его вряд ли можно назвать объектно-ориентированным в обычном понимании этих слов. — Tetromino 22:33, 31 мая 2010 (UTC)

• Требуется правка: следующая фраза содержит грамматические ошибки, так что смысл её неясен: "Если противопоставляется одиночное наследование множественному, то означает противопоставление технологии, позволяющей обойти множественное наследование, а именно применение интерфейсов".

"То означает" -- что означает? Наследование означает? Противопоставление означает?

Кроме того, после слов "а именно" следует поставить запятую. -- [[User:|Pancar]] 16:58, 18 июля 2011 (UTC)

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

Вообще, проблем множественного наследования в том виде, как они повсеместно воспринимаются, не существуют. Существуют проблемы реализации этой парадигмы в том или ином языке, и также существует задача (а не проблема) дизайна системы, которая сводится к множественному наследованию. Что касается проблем реализации, то это сугубо техническая сложность, и при программировании такой иерархии безусловно приходится идти на поводу технических ограничений и/или особенностей языка, но это не проблема множественного наследования как таковая. Что касается задачи дизайна, то она слабо соотносится с программированием, это задача дизайнера системы, автора её архитектуры. Задача же программиста - воплотить этот дизайн, и от его классности качество результата в общем-то не сильно и зависит.

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

Иметь множественное наследование интерейсов и не иметь множественного наследования реализаций - это, мягко говоря, нелогично. Во-первых, якобы "решение" проблемы множественного наследования перепроектированием её в агрегацию просто-напросто врёт, выдавая нагора не те взаимоотношения между классами, каковые требуются дизайном системы. Во-вторых, если агрегация якобы успешно справляется с подменой множественного наследования, она так же успешно должна справляться и с простым наследованием. Возникает вопрос, зачем тогда вообще нужно наследование, включая простое. В-третьих, проблема ромба, если уж рассматривать её как проблему, при наследовании интерфейсов стоит так же остро, проблемы со случайно совпавшими именами никуда не деваются и также должны решаться, задача разделения/совмещения аттрибутов также дожна решаться на уровне дизайна архитектуры и реализовываться явно по утверждённому дизайну. Я в принципе не вижу никаких объективных причин, кроме маркетинговых, политических и других, не имеющих отношения к IT, по которым отсутствие множественного наследования реализаций при наличии множественного наследования интерфейсов могло бы быть оправданным. Думаю, эти три абзаца имеет смысл добавить в статью, естественно подредактировав.

Для подраздела "Критика".

• Как уже говорил, проблема ромба - это фактически не проблема множественного наследования, а задача дизайна системы. Впрочем, не вижу причин тут что-то исправлять. Вероятно имеет смысл исправить и/или дополнить ту статью. Зато могу предложить исправить фразу так, чтобы в ней не фигурировал термин "семантическая неопределенность", ибо её по сути нет, а есть отражение дизайна системы в коде.
• Тут ссылок давать нет смысла, разве что на пункты Стандарта языка.
• Этот пункт в контексте C++ просто лжёт. Порядок наследования в рассматриваем контексте на семантику никак не влияет. В каком-нибудь Питоне или Перле порядок наследования влияет на семантику, т.к. компилятор выполняет поиск имён, в определённом порядке обходя дерево. В C++ все наследуемые методы фактически являются перегруженными (если они не скрыты в текущей области видимости), поэтому компилятор в процессе связывания имён и поиска кандидатов соберёт все подходящие кандидатуры в кучу и будет разрешать перегрузку, базируясь на списке доступных кандидатов в совокупности. Так что нет никакой разницы, в каком порядке указаны базовые классы. Опять же сослаться можно на Стандарт языка, но будет очень много пунктов.

Посему предлагаю вообще удалить ссылку на C++ из фразы перед списком. Нет причин там вообще что-то указывать, ибо проблемы эти довольно специфичны для каждого конкретного языка. -- Qraizer 05:41, 29 октября 2011 (UTC)