Для тех, кто не в курсе: существует два основных способа привнести в класс новую функциональность при проектировании ПО: агрегация и наследование.

Для "человека с улицы":
агрегирование - внесение ссылок на некие внешние сущности, которые декларировали некоторую функциональность. Объект, в свою очередь тоже начинает выдавать себя за подобные сущности, если переадресует всю (или часть) работы по этим ссылкам сторонним исполнителям.
наследование - ... - ну, в общем это нечто каличное, по логике, но чрезвычайно приспособленное к наработкам в сфере теории компиляции и логическим эквилибрам, благодаря которым не нужно делать те же пассы руками, что и при агрегировании, а всё их совершает компилятор (по вашим декларациям в программе) и, кроме того, проявляется свойство полиморфизма, когда экземпляры данного класса могут выступать в роли тех классов, от которых данный класс унаследован.
(думаю, всё стало ясно? )

В бытность преподом и сейчас - по софтовым фирмам, раздавал и раздаю задания на анализ и построение моделей предметных областей.

И выяснилась очень интересная закономерность!

Определённая группа лиц (сами знаете, - кто ), почему-то (с маниакальным упорством - хоть ставки делай), выбирала наследование. ДАЖЕ в случае явного идиотизма ситуации!
Например, в проекте по созданию ПО для ресторанного бизнеса такой вот "умный мальчик" (с "участием в нескольких успешных проектах с применением ООП и современных средств разработки ПО"), УНАСЛЕДОВАЛ в классе "заказ в ресторане" ОТ класса "заказчик" и класса "блюдо". То есть у него экземпляры класса заказ могли выступатьи в роли блюда и в роли человека - если кто не в теме...

Но, самый частый случай (даже с "ОПЫТНЫМИ" программистами) - это просто мой фольклор уже:
Во многих библиотеках классов есть класс "Поток" (не "Stream" который, а - "Thread"). И почти в 95% процентов случаев (обратное, среди этой категории граждан - единицы), если в процессе анализа предметки была выявлена "активная сущность со связями со многими клиентами", то гражданами выбиралось НАСЛЕДОВАНИЕ от класса "поток", а не проектирование класса (например) "задание", с последующей агрегацией списка экземпляров этого класса в серверный класс.
Здесь прикол с проектирование другой - тоньше. Дело в том, что поток - сущность достаточно низкого уровня и не входит в предметку. По сути разработчик его должен максимально скрыть. А свойство "потоковости" будут, как заячьи уши, торчать их сущностей, которые соверщенно не имеет дело с уровнем реализации ОСью многозадачности и средств синхронизации - Оккам в гробу, короче, переворачивается.

В то же время "лица коренной национальности" почти всегда начинали с агрегации и более полнее вводили отношения делегирования полномочий, при "разброске" ответственности за реализацию заявленной функциональности...

Может здесь довлеет какой-то более глубокий принцип или фактор, "вбитый" папами и мамами с воспитанием и воспринятым мироощущением от них?