继承与可测试性的组合

Question

在设计我的对象时，我发现从可测试性的角度来看，组合是更好的选择。原因是，如果需要的话，我可以在运行单元测试时模拟部分组合结构。如果我有一个继承层次结构，这是不可能的。

我想知道其他人是否也发现这是喜欢作曲的理由。还有什么其他可测试性陷阱，因为使用了继承？

Answer 1

我相信你越是开始使用设计模式开发，你会越来越多地发现组合比继承更受青睐。我实际上相信 Head First：Design Patterns 一书，“赞成过继承继承”是主要的设计原则之一。

你能够模拟部分组合物进行测试的例子可能是最好的例子之一。

编辑：虽然设计模式的基本原则是支持组合而不是继承，但这并不意味着没有设计模式在需要的地方使用继承。另一个基本的例子是装饰器模式，你在这里编写一个抽象的超类（虽然这是用于类型匹配而不是用于实现“is-a”关系）。

Answer 2

这不是一种情况。他们不是竞争对手。

继承也很容易进行单元测试。但是，它有时需要模拟具体类来测试抽象超类。

继承很容易被错误地使用。有些设计看起来像“is-a”情况，但实际上并非如此 - 它们更加细致入微。有时候，你需要某种组合（例如策略）将行为与其他属性分开，这真的是“行为式”。

Answer 3

The Gang of Four Design Patterns一书基本上都是关于为什么更喜欢构图而不是继承，并提供了许多方法来做到这一点。一些原因：

1. 类增加了代码库的复杂性

2. 在许多较新的语言中，继承仅限于一个类，而您可以根据需要进行构建
3. 基本类不能在运行时更改（基本上是您遇到的问题）。

Answer 4

我认为组合更容易测试的最大原因是（实现）继承倾向于创建非常脆弱的（脆弱的基类）并且更难以单独测试的非常耦合的类。

继承肯定有它的用途，但我发现自己越来越喜欢组合而不是继承。

Answer 5

“赞成对象组合超过类继承”实际上来自GoF书。这篇conversation与Erich Gamma在书中描述了这个想法。

需要继承的一个重要模式是模板方法模式。这种模式被广泛使用非常方便，所以继承就在这里。另一种使用继承的常见模式是Composite模式。我试图提出的一点是，根本不打折继承，但我希望通过查看这么多常见的API来清楚显示......

Answer 6

这取决于上下文。当类很简单并且从简单的公共类（配置/记录器）继承时，继承就赢了。我在其他情况下作文大多赢