Цитата:
Сообщение от JackFromChaos
предпочитайте композицию наследованию классов"(с) Банда четырех.
|
Кто это сказал? Плохая идея.
Задача: "Человек - наследник безмозглой обезьяны. У него есть мозг".
Реализация в таком вот подходе:
"Человек - оболочка с обезьяной внутри. Плюс у него есть мозг".
Реализация в подходе наследования:
"Человек – следующие звено в развитии обезьяны. У него есть мозг."
По-моему, второе звучит более логично.
Привожу сравнительную характеристику собственного производства.
«Наследование-включение»:
«+»
1. Возможность реализовывать функции-провайдеры в наследнике («Декоратор»). Таким образом мы можем запретить к использованию некоторые методы отца (Тут следует заметить, что то же самое можно реализовать и в подходе наследования, но в таком случаи это будет менее естественно для данного подхода).
2. Можно множественно наследовать там, где множественно наследовать нельзя.
«-»
1. Минус - громоздкий код («Декоратор» всегда громоздок).
2. Уничтожение одного из подходов к построению логики кода. Таким образом мы не сможем никак выделить архитектурой родственность между объектами.
«Наследование-наследование»:
«+»
1. Реализует стандарт С++.
2. Изящно – нет лишнего кода.
3. Минус один уровень вызова через точку.
«-»
1. Сложно представить. При неправильном подходе может вызвать захламлённость структуры.
2. Требует умения думать абстрактно.
Цитата:
Сообщение от JackFromChaos
Вообще почитайте "Приемы объектно ориентированного проектирование - паттерны проектирования". Глава введение, раздел "наследования и композиция".
|
Я читал книгу по шаблонам авторства Гамма. Почти все книги по паттернам рассматривают java-подобные подходы к архитектуре, где множественное наследование заменено интерфейсами.
Цитата:
Сообщение от JackFromChaos
В результате программист зависит не от логики, а от реализации компилятора...
|
Множественное наследование присуствует в стандарте С++. Любой компилятор под него обязан реализовывать множественное наследование.
Думаю, Страуструп дураком не был.