дизайн шаблона сочинять или наследовать?

Question

Большинство людей предпочитают составлять по наследству,

но какова значительная выгода для этого?

Answer 1

Эта статья должна дать вам полный ответ: Принципы проектирования из шаблонов проектирования: композиция против наследования

Я цитирую прямой ответ Эриха Гаммы здесь:

Я все еще думаю, что это правда, даже после десяти лет. Наследование - это крутой способ изменить поведение. Но мы знаем, что это хрупко, потому что подкласс может легко делать предположения о контексте, в котором вызывается метод, который он переопределяет. Между базовым классом и подклассом существует тесная связь из-за неявного контекста, в который будет вызываться код подкласса, который я подключаю. Композиция обладает более приятным свойством. Связность уменьшается благодаря наличию более мелких вещей, которые вы подключаете к чему-то большему, и больший объект просто вызывает меньший объект обратно. С точки зрения API определение того, что метод может быть переопределен, является более строгим обязательством, чем определение того, что метод может быть вызван.

В подклассе вы можете делать предположения о внутреннем состоянии суперкласса, когда вызывается метод, который вы переопределяете. Когда вы просто включаете какое-то поведение, тогда это проще. Вот почему вы должны отдать предпочтение композиции. Распространенным заблуждением является то, что композиция вообще не использует наследование. Композиция использует наследование, но обычно вы просто реализуете небольшой интерфейс и не наследуете от большого класса. Идиома слушателя Java - хороший пример для композиции. С помощью слушателей вы реализуете интерфейс слушателя или наследуете от того, что называется адаптером. Например, вы создаете объект слушателя и регистрируете его с помощью виджета Button. Нет необходимости создавать подкласс Button для реагирования на события.

Answer 2

Потому что наследство - зло

Answer 3

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

Answer 4

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

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

Answer 5

, поскольку новый класс не полностью квалифицируется как нечто, что может быть помещено в иерархию «наследования» для этого конкретного «базового класса» ...

значительные преимущества:

опция расширения другого класса всегда доступна

вы не привязаны к реализации и определению базового класса

Answer 6

В языках, которые не поддерживают множественное наследование, вы не «сжигаете» свой единственный шанс наследовать от другого класса (типа).

Кроме того, это может быть более подходящим моделированием проблемной области.