Классик ООП и проектирования о множественном наследовании

Бертран Мейер, один из главных вдохновителей ООП-проектирования, автор принципа "open-close" SOLID(буква O) пишет следующее:

Множественное наследование (Multiple inheritance)
Часто необходимо сочетать различные абстракции. Рассмотрим класс, моделирующий понятие "младенец". Его можно рассматривать как класс "человек" с компонентами, связанными с этим классом. Его же можно рассматривать и более прозаично - как класс "элемент, подлежащий налогообложению", которому положены скидки при начислении налогов. Наследование оправдано в обоих случаях. Множественное наследование (multiple inheritance) - это гарантия того, что класс может быть наследником не только одного класса, но многих, если это концептуально оправдано.

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

Класс должен иметь возможность быть наследником нескольких классов.

Конфликты имен при наследовании разрешаются адекватным механизмом.

Решение, разработанное в этом курсе, основано на переименовании конфликтующих компонентов у класса наследника.

Дублируемое наследование (Repeated inheritance)
При множественном наследовании возникает ситуация дублируемого наследования (repeated inheritance), когда некоторый класс многократно становится наследником одного и того же класса, проходя по разным ветвям наследования:

Дублируемое наследование

Рис. 2.1. Дублируемое наследование
В этом случае язык должен обеспечить точные правила, определяющие, что происходит с компонентами, наследованными повторно от общего предка (на рисунке - это A). В некоторых случаях желательно, чтобы компонент из A создавал только один компонент в D ( разделение ), а в других - нужно, чтобы он создавал два ( дублирование ). Разработчики должны обладать гибкими средствами, позволяющими предписывать одну из возможностей независимо для каждого компонента.

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

Добавлено через 14 минут
ссылка на классику ООП-проектирования:
http://www.intuit.ru/studies/c... 114?page=3

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

0

Сообщение от strategyquest К сожалению, в наше время не все дизайнеры ООП-языков способны справляться с адекватной реализацией наследования, поэтому, вместо этого часто запускается маркетинговая утка о том, что оно, якобы, лишнее, и даже иногда утверждается о его "вредности"

Страуструп с этим справился на ура. Только как понимаю далеко не все удосужились прочитать правила управления дублированием/разделением.

0