Каковы преимущества/недостатки варианта 2 по сравнению с 1 в этом примере?Каковы преимущества использования композиции над наследованием, когда нам нужно добавить поведение в список <>?
Вариант 1 (Наследование):
public class SalesList : List<Sales>
{
//methods that add extra behavior List<Sales>
}
Вариант 2 (состав):
public class SalesList
{
private List<Sales> _list;
//methods that add extra behavior to List<Sales>
}
Вариант 1
- Преимущества - все преимущества наследования & повторного использования
- Недостатки - код теперь сигнализации для потребителей, что она dervied из списка. Если это необходимо изменить позднее, все затронутые потребители будут затронуты.
Вариант 2
- Преимущества - информация о реализации данных о продажах абстрагируется от потребителей. Итак, если реализация должна измениться (например, словарь), потребитель этого класса будет невосприимчив к этим изменениям.
- Недостатки - класс SalesList теперь должен выставлять дополнительные методы для получения и/или установки внутреннего объекта _list. это дополнительный код, который необходимо сохранить. Кроме того, если внутренняя реализация меняется, вам нужно позаботиться о том, чтобы все еще поддерживать предыдущее поведение ...
Всего несколько мыслей, которые приходят на ум.
HTH.
Преимущество варианта 2 является маневренность. Используя композицию, вы можете выбрать, какие части интерфейса списка вы выставите.
Представьте себе, что позже вы решите больше не распространяться из другого класса. К настоящему времени некоторые пользователи вашей библиотеки будут использовать методы, предоставляемые List, поэтому вам нужно реализовать все методы списка самостоятельно: add/addAll/contains/retainAll. Это очень много методов для реализации для простого списка продаж.
В принципе, это сводится к «когда есть сомнения, оставьте это», о котором говорит Джошуа Блох в номере Bumper-Sticker API Design. Каждый аспект API должен быть как можно меньше, но не меньше. Вы всегда можете добавить вещи позже, но вы не можете их отнять.
Основным недостатком композиции является то, что вам необходимо обернуть (дублировать) все общедоступные методы частного списка, если вам нужно представить один и тот же интерфейс, в Inheritance у вас есть все они уже доступны, но вы не можете переопределить любой из них, который был сделан недопустимым (в C# это означает, что метод должен быть помечен как «virtual», в Java он не может быть помечен как «final»).
В C# 3 и выше вы можете использовать методы расширения, которые дают внешний вид наследования без портирования дерева иерархии.
Большим недостатком является то, что вы не сможете передать «SalesList», чтобы любой метод, который написан, чтобы ожидать «Список
В составе вы можете динамически изменять реализацию суперкласса во время выполнения. Но используя наследование, вы не можете изменить реализацию суперкласса во время выполнения.
В композиции это зависит от того, какой тип объекта вы проходите в сеттер, и он будет вести себя на основе этого.Это даст больше гибкости в реализации
Наследование позволяет формировать иерархию классов, таким образом, что родитель является * супер * набор и все его ребенка являются * суб * набор, который позволяет обобщение, специализация и применять substitution principle
Возможный дубликат http://stackoverflow.com/questions/1598722/should-i-use-inheritance-or-composition – Lucero