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



Решение лежит паттерне шаблонный метод.
Производный класс становится в принципе не очевиден, нужно исследовать его иерархию наследования;
- Производный класс сильно зависит от базового класса и любые изменения в базовом классе скажутся на производном — это проблема т.е. тебе нужно контролировать изменения базового класса. А если изменился базовый класс, то нужно проверить все производные. Частичное решение — соблюдение базовыми классами принципа открыт/закрыт.;
- Производный класс получает все зависимости базовых классов и есть вероятность нарушения SRP;
- Опасность нарушения LSP;
- Использование наследования тогда когда в принципе этого делать нельзя т.е. в случаях когда нет отношения“является”, когда причина это нужда в каком-то интерфейсе или нужда в какой-то реализации;
Возможно это не все пункты, но если вспомню/узнаю — то дополню.
Чем лучше композиция? Тем что это концепция модульности т.е. есть части которые мы можем заменять, использовать повторно и не разбираться в деталях.
update:
Хотя наследование тоже является частью концепции модульности в том плане что мы расширяем новыми сервисами.
