Байланысты: Бьерн Страуструп. Язык программирования С . М Бином, 2011
12.1.2 Игнорирование наследования Рассмотрим вариант 2 - проект, который игнорирует наследование. В этом случае в окончательной
программе просто не используются возможности основного средства С++, хотя и получаются
определенные выгоды при использовании С++ по сравнению с использованием языков С, Паскаль,
Фортран, Кобол и т.п. Обычные доводы в пользу этого, помимо инерции, утверждения, что
"наследование - это деталь реализации", или "наследование препятствует упрятыванию информации",
или "наследование затрудняет взаимодействие с другими системами программирования".
Считать наследование всего лишь деталью реализации – значит игнорировать иерархию классов,
которая может непосредственно моделировать отношения между понятиями в области приложения.
Такие отношения должны быть явно выражены в проекте, чтобы дать возможность разработчику
продумать их.
Сильные доводы можно привести в пользу исключения наследования из тех частей программы на С++,
которые непосредственно взаимодействуют с программами, написанными на других языках. Но это не
является достаточной причиной, чтобы отказаться от наследования в системе в целом, это просто
довод в пользу того, чтобы аккуратно определить и инкапсулировать программный интерфейс с
"внешним миром". Аналогично, чтобы избавиться от беспокойства, вызванного путаницей с
упрятыванием информации при наличии наследования, надо осторожно использовать виртуальные
функции и закрытые члены, но не отказываться от наследования.
Существует достаточно много ситуаций, когда использование наследования не дает явных выгод, но
политика "никакого наследования" приведет к менее понятной и менее гибкой системе, в которой
наследование "подделывается" с помощью более традиционных конструкций языка и проектирования.
Для больших проектов это существенно. Более того, вполне возможно, что несмотря на такую политику,
наследование все равно будет использоваться, поскольку программисты, работающие на С++, найдут
убедительные доводы в пользу проектирования с учетом наследования в различных частях системы.
Таким образом, политика "никакого наследования" приведет лишь к тому, что в системе будет
отсутствовать целостная общая структура, а использование иерархии классов будет ограничено
определенными подсистемами.
Иными словами, будьте непредубежденными. Иерархия классов не является обязательной частью
всякой хорошей программы, но есть масса ситуаций, когда она может помочь как в понимании области
приложения, так и в формулировании решений. Утверждение, что наследование может неправильно
или чрезмерно использоваться, служит только доводом в пользу осторожности, а вовсе не в пользу
отказа от него.