我昨天在继承自 Bar 的 Foo 类中写了这个：
public override void AddItem(double a, int b)
{
//Code smell?
throw new NotImplementedException("This method not usable for Foo items");
}
后来想知道这是否可能表明我应该使用 Bar，而不是从它继承。
还有哪些“代码味道”可以帮助在继承和组合之间做出选择？
EDIT我要补充的是，这是一个sn-p，还有其他方法是共同的，我只是不想太详细.我必须分析切换到作曲的含义，并想知道是否可能存在其他“代码气味”有助于打破平衡。
【问题讨论】：
标签： oop inheritance composition
您上面给出的示例显然是代码异味。 AddItem 方法是基类Bar 的一种行为。如果Foo 不支持AddItem 行为，它不应该从Bar 继承。
让我们考虑一个更现实的 (C++) 示例。假设您有以下课程：
class Animal
{
void Breathe() const=0;
}
class Dog : public Animal
{
// Code smell
void Breathe() { throw new NotSupportedException(); }
}
基础抽象类Animal 提供了一个纯虚Breathe() 方法，因为动物必须呼吸才能生存。如果它不呼吸，那么根据定义，它就不是动物。
通过创建一个继承自 Animal 但不支持 Breathe() 行为的新类 Dog，您违反了 Animal 类规定的合同。这只可怜的狗活不下去了！
公共继承的简单规则是，只有在派生类对象真正“是”基类对象时才应该这样做。
在您的特定示例中：
Foo 不支持Bar 合约规定的AddItem() 行为。Foo“不是”Bar，不应继承自它。【讨论】：
那么，如果没有扩展的 Foo 的行为不像 Bar，为什么要从 Bar 继承呢？ 想想看，我什至不会在基类中将像“AddItem”这样的方法声明为虚拟的。
【讨论】：
不！正方形可能是长方形，但 Square 对象绝对不是 矩形对象。为什么？因为 Square 对象的行为不是 符合a的行为 矩形对象。 在行为上，一个 正方形不是矩形！它是 软件就是一切的行为 关于。
来自 Object Mentor 中的 The Liskov Substitution Principle。
【讨论】：
是的，您必须“取消实现”方法表明您可能不应该使用“is-a”关系。您的 Foos 似乎并不是真正的 Bars。
但首先要考虑您的 Foos 和 Bars。是Foos酒吧吗？你能在纸上画出集合和子集吗，每个 Foo（即 Foo 类的每个成员）也会是 Bar（即 Bar 类的成员）吗？如果不是，您可能不想使用继承。
另一个表明 Foo 不是真正的 Bars 并且 Foo 不应该继承 Bar 的代码异味是您不能使用多态性。假设您有一个将 Bar 作为参数的方法，但它无法处理 Foo。 （可能是因为它在其参数中调用了 AddItem 方法！）您必须添加一个检查或处理 NotImplementedException，这使代码变得复杂且难以理解。 （还有气味！）
【讨论】：
当然也有直接的反面，如果你的 Foo 实现了很多只将消息转发到它拥有的 Bar 的接口，这可能表明它应该是一个 Bar。只是，气味并不总是正确的。
【讨论】：
虽然上面的示例可能表明出现了问题，但 NotImplementedException 本身并不总是错误的。这都是关于超类的契约和实现这个契约的子类。如果你的超类有这样的方法
// This method is optional and may be not supported
// If not supported it should throw NotImplementedException
// To find out if it is supported or not, use isAddItemSupported()
public void AddItem(double a, int b){...}
那么，合同不支持这种方式还是可以的。如果不支持，您可能应该禁用 UI 中的相应操作。所以如果你对这样的契约没问题，那么子类就会正确地实现它。
当客户端明确声明它不使用所有类方法并且永远不会使用时的另一个选项。像这样
// This method never modifies orders, it just iterates over
// them and gets elements by index.
// We decided to be not very bureaucratic and not define ReadonlyList interface,
// and this is closed-source 3rd party library so you can not modify it yourself.
// ha-ha-ha
public void saveOrders(List<Order> orders){...}
然后可以传递不支持添加，删除和其他变异器的列表实现。只需记录它。
// Use with care - this implementation does not implement entire List contract
// It does not support methods that modify the content of the list.
public ReadonlyListImpl implements List{...}
虽然让你的代码来定义你的所有合约是好的，因为它让你的编译器来检查你是否违反了合约，但有时这是不合理的，你必须求助于弱定义的合约，比如 cmets。
简而言之，问题在于，如果您真的可以安全地将您的子类用作超类，考虑到超类是由其合同定义的，而不仅仅是代码。
【讨论】：
.Net 框架有这样的示例，尤其是在 System.IO 命名空间中 - 一些阅读器没有实现其所有基类属性/方法，如果您尝试使用它们会抛出异常。
例如流有一个位置属性，但有些流不支持这个。
【讨论】：
组合是preferable 继承，因为它降低了复杂性。更好的方法是使用 constructor injection 并在 Foo 类中保留对 Bar 的引用。
【讨论】：