Наследование против композиции, что предпочтительнее? 
Недавно, мне предложили провести серию небольших семинаров по объектно ориентированному программированию. Я согласился. И вот теперь пытаюсь накидать конспект лекции по инкапсуляции и наследованию.
Пока написал некоторые основные тезисы, которые хочу развить до полноценной лекции. Хотелось бы увидеть в комментариях ваше мнение о том, что написано.
Основная цель ООП заключается в том, чтобы код создаваемый в одном месте можно было использовать в разных местах программы. При этом сам код не дублируется. Для реализации этой цели у программиста есть два мощных метода - наследование и композиция. И у того и у другого метода есть как достоинства так и недостатки. Но тем ни менее злоупотребление наследованием в конечном счете может стоить разработчику гораздо дороже нежели использование композиции.
Самый большой недостаток наследования заключается в том, что оно легко нарушает один из базовых принципов ООП - инкапсуляцию. Это связано с тем, что фактически родительский класс определяет поведение дочернего класса, а это значит, что даже незначительное изменение в родительском классе может сильно сказаться на поведении класса-потомка. Плюс ко всему, повторное использование кода сильно затрудняется, если реализация родителя содержит аспекты несовместимые с задачами потомка. Как правило, чтобы выйти из такой ситуации необходимо провести глубокий рефакторинг кода, а это не всегда возможно.
На практике, чтобы избежать зависимости от реализации, предпочтительнее наследовать абстрактные классы (или интерфейсы). Тогда класс-потомок может сам определить каким образом реализовать свою работу.
В противовес наследованию, часто используется другой метод - композиция.
Композиция объектов строится динамически за счет связывания одного объекта с другими. При таком подходе классы используются в соответствии с их интерфейсом. Что не нарушает инкапсуляцию. Использование единого интерфейса позволяет в дополнение к инкапсуляции получить преимущества полиморфизма. Т.е. во время выполнения программы возможно один объект заменить другим, при условии, что у него такой же интерфейс.
Исходя из сказанного можно вывести два важных правила:
Первое правило: программируйте в соответствии с интерфейсом, а не реализацией.
Второе правило: предпочитаете инкапсуляцию наследованию.
Следование данным правилам, в конечном счете, позволит вам писать более гибкие программы.
P.S. запустил обсуждение наследование против композиции
подписаться на блог
dkrnl
Гость
в контексте какого языка обсуждение?
ведь очень важно наличие или отсутствие: method overloading, method mixing…
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
dkrnl, мне кажется, что язык таки не очень важен. Не столько важна техническая реализация, сколько общая идея о том как должен быть построен код.
Leave a Reply