Основная цель ООП заключается в том, чтобы код создаваемый в одном месте можно было использовать в разных местах программы. При этом сам код не дублируется. Для реализации этой цели у программиста есть два мощных метода – наследование и композиция. И у того и у другого метода есть как достоинства так и недостатки. Но тем ни менее злоупотребление наследованием в конечном счете может стоить разработчику гораздо дороже нежели использование композиции.

Самый большой недостаток наследования заключается в том, что оно легко нарушает один из базовых принципов ООП – инкапсуляцию. Это связано с тем, что фактически родительский класс определяет поведение дочернего класса, а это значит, что даже незначительное изменение в родительском классе может сильно сказаться на поведении класса-потомка. Плюс ко всему, повторное использование кода сильно затрудняется, если реализация родителя содержит аспекты несовместимые с задачами потомка. Как правило, чтобы выйти из такой ситуации необходимо провести глубокий рефакторинг кода, а это не всегда возможно.

На практике, чтобы избежать зависимости от реализации, предпочтительнее наследовать абстрактные классы (или интерфейсы). Тогда класс-потомок может сам определить каким образом реализовать свою работу.

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

Композиция объектов строится динамически за счет связывания одного объекта с другими. При таком подходе классы используются в соответствии с их интерфейсом. Что не нарушает инкапсуляцию. Использование единого интерфейса позволяет в дополнение к инкапсуляции получить преимущества полиморфизма. Т.е. во время выполнения программы возможно один объект заменить другим, при условии, что у него такой же интерфейс.

Исходя из сказанного можно вывести два важных правила:

Первое правило: программируйте в соответствии с интерфейсом, а не реализацией.

Второе правило: предпочитаете инкапсуляцию наследованию.

Следование данным правилам, в конечном счете, позволит вам писать более гибкие программы.