// codeart.ru / Статьи / Наследование против композиции, что предпочтительнее? Форум

Наследование против композиции, что предпочтительнее? rss подписка

Автор: Evgeny Sergeev

Недавно, мне предложили провести серию небольших семинаров по объектно ориентированному программированию. Я согласился. И вот теперь пытаюсь накидать конспект лекции по инкапсуляции и наследованию.

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

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

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

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

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

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

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

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

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

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

P.S. запустил обсуждение наследование против композиции

  1. Немного о behaviour тестировании в TDD
  1. в контексте какого языка обсуждение?
    ведь очень важно наличие или отсутствие: method overloading, method mixing…

  2. dkrnl, мне кажется, что язык таки не очень важен. Не столько важна техническая реализация, сколько общая идея о том как должен быть построен код.

Leave a Reply

« Приобрел HTC desire. Некоторые ошибки проектирования »

 

Кровля по доступным ценам. Скидки: доборные элементы кровли. | Доставить для машин шины Kumho | принтеры Калининград | Оригинальные подарки | Карта блога.