belugin

Вот именно поэтой причине (код выше) и возникают мысли, что наследование главное зло на планете и следует всеми возможными способами его избегать :)

"Число ног" - это просто изменяемое свойство "Собаки". При помощи наследование можно создавать классификации только на основе неизменяемых свойств объектов. Классификации на основе изменяемых свойств (перееханные и перетраханные собаки) - в основном ноненс.


GKS_Samara
"иначе конфликтует требование к конкретной функциональности и идеи для потомков".

Если LSP не нарушается, то всё будет в порядке.
Можно в свободное время помедитировать над классом Object c методами Equals, HashCode.
Или посмотреть на шаблон Composite в различных имплементациях.

softwarerКрасота такого подхода легко демонстрируется на простом примере. Допустим, я хочу сделать компонент "как JLabel", но в дополнение к его функционалу обладающий еще какой-нибудь мелкой деталью. Например, приобретающий красный цвет, если надпись в нем содержит грамматическую ошибку. Естественное решение - наследоваться от JLabel.

Вот сейчас смотрю на иерархию (все имена вымышленные, любые совпадения считать случайными):


и думаю: а всякое ли "естественное решение" небезобразно? :)

softwarer
Тем не менее, принципа это ничуть не трогает. Задача "взять и немного доработать напильником" - одна из наиболее распространенных в практическом программировании.

Если мы вдруг попробуем решать ее не наследованием - натолкнемся на две проблемы:

во-первых, необходимость строить иерархию классов, параллельную уже существующей (совершенно идиотское занятие и особенно при отсутствии множественного наследования; тот же Swing это хорошо показывает);

во-вторых, несовместимость наших классов со стандартными (как следствие - невозможность для любого стандартного кода, в том числе третьих авторов, работать с нашими объектами).


Доработка напильником не такая тривиальная задача как кажется. Хотя бы из-за того, что "дорабатывать" можно разными способами и нужно уметь сделать "правильный" выбор.
Усугубляется всё тем, что "правильный" выбор в кроткосрочной и долгосрочной перспективах получается совершенно различным.

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

Про иерархию выше, могу сказать только одно. Она бы существенно схлопнулась, если наследование было заменено декомпозицей. Н-р, созданием классов валидаторов, рендереров и т.д. Создавать по классу наследнику для каждого типа отображаемых значений в каждом из контекстов где оно может использоваться - бред. Это всё равно, что для Пети дома делать класс ПетяДома extends Человек, а для Пети на работе - класс ПетяНаРаботе extends Человек.
Благо, что ругаемый вами swing построен так, что позволяет задавать валидаторы, рендереры и иже с ними для станадртных компонент, что не приводит ни к возникновению параллельных иерархий, ни к не совместимости со стандартными классами. Если правильно готовить :)

Я это пишу не к тому, что принцип озвученный вами не имеет право на жизнь, а к тому, что необходимости думать он не отменяет.


0bsid
возможно глупый вопрос
как ты сделал такое представление иерархии ? ручками или утилитой кокой?
мне понравилось это простое и понятное текстовое представление дерева

Idea. Ctrl-H - смотрим на панель с деревом наследования. Затем выделяем интересующие классы, Ctrl-C, Ctrl-V в любимый текстовый редактор и руками ставим табуляцию.