原文链接 : Composition over Inheritance，What it means for your Activities 原文作者 : Josh Brown 译者 : chaossss 校对者: Mr.Simple 状态 : 完成  事实上我们在很多 Java 进阶书籍上看到过“开发时应该更倾向于选择组合而不是继承”的建议，为什么建议我们更倾向于而不是完全代替呢，因为当类 A 能完全代替另一个类 B（我们想让 B 成为 A 的父类）时，我们就应该使用继承，如果 A 仅仅是和 B 有着某些共同的行为，是不应该使用继承的（更多的讨论戳我）。然而，在我阅读别人的源码时，滥用继承的情况实在是太多了，多少人创建了一个 BaseActivity 后，就让所有 Activity 继承它，在子 Activity 中实现业务逻辑。  而且这样做问题大大的有，最鲜活的例子就是：Joe Newguy 加入到我们组，并实现了 ShinyFeatureActivity，那会组里没有任何规定强迫他必须让 ShinyFeatureActivity 继承于 BaseActivity，但他还是这么干了……万幸我们在 Code Review 时发现了这个问题。此外，如果每一个 Activity 都继承于 BaseActivity，在某些情况下，你可能要继承的是其他 Activity（例如：PreferenceActivity、ListActivity）。尽管大部分 Activity 的子类都有相应的 Fragment 代替，但还是有一部分是没有对应 Fragment 的，某些库仍然需要相应的 Activity 子类。  有些更潜在的问题是：有时候某些 Activity 需要这些行为，其他的 Activity 需要其他行为，而 Java 并不支持多继承，这就意味着我们得将行为有交集的 Activity 的所有行为放到一个独立的类里面。但这样做会降低可维护性，甚至带来性能影响。