При разработке моих объектов я считаю, что композиция является лучшим выбором с точки зрения проверяемости. Причина в том, что я могу высмеять части структуры композиции, если мне нужно, во время выполнения модульных тестов. Это невозможно, если у меня есть иерархия наследования.
Я хотел бы знать, считают ли другие это причиной предпочтения композиции. Кроме того, какие другие ловушки, связанные с тестируемостью, вы получили, потому что наследование было использовано?
Я считаю, что чем больше вы начинаете разрабатывать с использованием шаблонов дизайна, тем чаще вы обнаружите, что композиция будет предпочтительнее наследования. Я действительно верю в книгу Head First: Design Patterns, которая "Favor Composition Over Inheritance" является одним из основных принципов дизайна.
Ваш пример того, чтобы быть способным макетировать части композиции для тестирования, вероятно, является одним из лучших возможных примеров.
Изменить. Хотя основной принцип в шаблонах проектирования заключается в том, чтобы поддерживать композицию над наследованием, это не означает, что нет шаблонов проектирования, которые используют наследование там, где это необходимо. Другим основным примером является шаблон декоратора, в котором вы кодируете абстрактный суперкласс (хотя это относится к сопоставлению типов, а не к реализации отношения "is-a" ).
Это не либо - либо ситуация. Они не конкуренты.
Наследование довольно легко и для unit test. Однако иногда для проверки абстрактного суперкласса иногда требуются макеты конкретных классов.
Наследование можно легко использовать ненадлежащим образом. Некоторые проекты выглядят как "есть-а", но на самом деле они не очень тонкие. Иногда он действительно "ведет себя", когда вам нужна какая-то композиция (например, Стратегия), чтобы отделить поведение от других атрибутов.
Книга "Банда четырех" Design Patterns в основном состоит в том, почему предпочитают композицию над наследованием и предлагает множество способов сделать это. Некоторые причины:
Я думаю, что самая большая причина, почему композиция легче тестировать, заключается в том, что наследование (реализация) имеет тенденцию создавать очень связанные классы, которые являются более хрупкими (Fragile Base Class) и сложнее тестировать изолированно.
Наследование определенно имеет свои применения, но я считаю, что чаще всего предпочитаю состав над наследованием.
"Использовать композицию объекта над наследованием класса" на самом деле из книги GoF. Этот разговор с Эрихом Гамма описывает эту идею из книги.
Одним из важных шаблонов, требующих наследования, является шаблонный шаблон. Этот шаблон широко используется очень удобно, поэтому наследование здесь остается. Другим распространенным шаблоном, который будет использовать наследование, является композитный шаблон. То, что я пытаюсь сделать, это то, что вообще не налагайте наследование на наследство, но я надеюсь, что это ясно, просто глядя на так много общих API-интерфейсов в любом случае...