在此示例中，选项 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>
}
【问题讨论】：
标签： inheritance oop composition
选项 2 的优点是敏捷。使用组合，您可以选择要公开的列表界面的哪些部分。
想象一下，稍后您决定不再从另一个类扩展。到目前为止，您的库的一些用户将使用 List 提供的方法，因此您需要自己实现所有列表方法：add/addAll/contains/retainAll。对于一个简单的销售列表，有很多方法可以实现。
基本上，这归结为 Joshua Bloch 在Bumper-Sticker API Design 中谈到的“如有疑问，请忽略它”。 API 的每个方面都应该尽可能小，但不能更小。以后你可以随时添加东西，但你不能把它们拿走。
【讨论】：
Composition 的主要缺点是，如果您需要呈现相同的接口，则需要包装（复制）私有 List 的所有公共方法，在 Inheritance 中您已经拥有所有这些方法，但您不能覆盖它们中的任何一个都是不可覆盖的（在 C# 中，这意味着该方法应标记为“虚拟”，在 Java 中不能标记为“最终”）。
在 C# 3 及更高版本中，您可以使用扩展方法，它提供继承的外观，而不会真正弄乱层次结构树。
【讨论】：
SalesList 传递给任何编写为期望List<Sales> 或通用List<T> 的方法。重写所有List 方法可能很烦人，但几乎不可能。如果没有代码的方法需要List<Sales>，则使用该方法可能很困难或不可能。泄露对内部列表的引用似乎可以解决这个问题，但会产生更多问题。因为List 的很多方法都是非虚的，所以派生类不能太大地改变它的行为；一个人无论做什么都可能被卡住。
继承允许我们形成类的层次结构，这样父类是*super*set，其所有子类都是*sub*set，这允许泛化，专业化和申请substitution principle
【讨论】：
选项 1
- 优点 - 继承和重用的所有优点
- 缺点 - 代码现在向消费者发出信号，表明它来自 List。如果这需要在以后更改，那么所有相关的消费者都会受到影响。
选项 2
- 优点 - 关于存储销售数据的实现细节从消费者那里抽象出来。因此，如果实现需要更改（例如字典），该类的使用者将不受这些更改的影响。
- 缺点 - SalesList 类现在需要公开其他方法来获取和/或设置到内部 _list 对象。这是需要维护的附加代码。此外，如果内部实现发生变化，您需要注意仍然支持以前的行为......
只是想到了一些想法。
HTH。
【讨论】：
在组合中，您可以在运行时动态更改超类实现。 但是使用继承你不能在运行时改变超类的实现。
在组合中，它取决于你传递给 setter 的对象类型，它会根据它来表现。它将为实施提供更大的灵活性
【讨论】：