Существуют ли какие-либо рекомендации относительно максимальной глубины иерархии наследования для структуры и руководящих принципов, когда использовать несколько уровней наследования или присоединяться к ним в одном классе?
Некоторые ссылки на установленные практики/примеры, которые хорошо работали в мире Java, были бы приятными в ответах, поскольку это с точки зрения сообщества и фреймворков, окружающих Java.
Возможно, вы ищете хорошее правило вроде "не более 5 уровней наследования", но я действительно сомневаюсь, что существует такое правило. Объекты обычно моделируют объекты реального мира, и сообщество всех этих лиц никогда не соглашалось с правилом (насколько я знаю)...
Одна "лучшая практика" определенно: предпочитает композицию над наследованием. Следуя этому руководству: определите один интерфейс и реализации без дополнительных суперклассов. Все общие поля и методы имеют поведение и стратегии
С другой стороны, мы когда-нибудь моделируем объекты или структуры реального мира, которые уже имеют глубокую иерархию сущностей. Классификация животных - один из примеров или алгебраические структуры. Рамки для моделирования таких существующих структур потребуют глубокой иерархии классов, потому что она должна следовать реальному миру, чтобы быть понятным.
По моему мнению, каждый производный класс является "классом его собственного", а клиенты этого класса, включая подклассы), вообще не беспокоят или не интересуются тем, сколько классов существует между этим классом и Object.
Таким образом, мой ответ был бы следующим: Нет, пусть иерархия будет такой же глубокой, насколько она должна быть, если это имеет смысл/кажется логичным. Не позволяйте глубине иерархии влиять на решение о свертывании двух классов. Поскольку каждый подкласс является уточнением его базового класса, мой опыт говорит, что редко имеет смысл иметь глубину более 5 или 6 классов.
Просто чтобы быть ясным: как указывали другие, вы должны одобрять композицию над наследованием. Для меня, однако, это похоже на несколько иной вопрос.
Согласно этой статье, максимальная глубина стандартного Java API составляет 9.
Из того, что я видел (обратите внимание: это не официальное мнение, только мои наблюдения), 3-4 является разумным максимумом.
Также помните одну важную часть из Effective Java:
Использовать композицию над наследованием
Я думаю, с точки зрения обслуживания, как мелкая иерархия наследования, как вы можете управлять, это путь. Трассировка ошибок на нескольких иерархических уровнях, а затем необходимость выяснить, на каком уровне они должны быть исправлены, может быть сложным.
Не существует лучших практик относительно максимальной глубины наследования. Вместо того, чтобы искать его в объеме, это правило, когда дело доходит до наследования в java (и любой язык OO, если на то пошло).
1_ Прежде чем внедрять проверку наследования, истинно ли отношение "является". Зарядное устройство - это автомобиль. (так что наследование прекрасное). Если вы это сделаете, то в любом случае вы не получите огромное дерево наследования. (Колесо не автомобиль, поэтому наследование здесь не так)
2_ Если "is a" отношения терпят неудачу или у вас есть двусмысленность, тогда вероятное наследование не так. Вам нужно идентифицировать общность между вашими классами и использовать композицию (рефакторинг общего кода для нового класса).
3_, если вы хотите установить иерархию типа, тогда вы должны пойти с наследованием интерфейса (Тип), а не наследование уровня класса. (Может быть, некоторые из этих заявлений требуют больше объяснений, но для этого вам, вероятно, нужно забрать какую-нибудь книгу.)
Сначала вы должны подумать о ясности кода, который вы пишете. Будет ли более высокий уровень глубины сделать код более легким для чтения и обслуживания или это сделает его сложнее. В зависимости от проблемы, которую вы пытаетесь решить.
Как показывают другие плакаты, вы можете сделать глубину слишком мелкой или слишком глубокой. Это проблема с иглами ИМХО.
Лучше всего, чтобы каждый класс заботился о кучу подобных вещей.
Каждый метод внутри этого класса заботится об одном действии/поведении.
Посмотрите на эту refcard из DZone: http://refcardz.dzone.com/assets/download/refcard/54c22c8b0a53591ea9e0504fdfd4bada/rc130-010d-designing-quality_0.pdf
Общее правило - это глубже иерархии, тем труднее было бы понять, где определенные методы и поля определены или/и переопределены.
Но помимо наследования существуют другие факторы, которые необходимо соблюдать, чтобы сохранить сложность кода.
Лучший подход - использовать инструмент метрики кода и попытаться сбалансировать различные факторы (строки кода, развязки классов и...)
Когда дело доходит до лучших практик, следует учитывать производительность (использование памяти).
Он будет использовать больше памяти, если у вас есть глубокая иерархия классов (не абстрактный). Подобно созданию нового объекта последнего дочернего 3-го уровня, наследование будет использовать МЕНЬШЕЕ ПАМЯТЬ, чем 9-наном уровне. Основываясь на характере применения, этот пункт можно было бы рассмотреть в дополнение к другим сообщениям.