【第14条】复合优先于继承

    继承（指的是子类扩展超类，并不包含接口）是实现代码重用的有力手段，但它并不总是完成这项工作的最佳工具。不适当地使用继承会导致脆弱的软件。

 

    与方法调用不同的是，继承打破了封装性。换句话说子类依赖于超类中特定功能的实现细节。超类的实现可能随着发行版本而变化，就有可能影响子类。因此，子类必须要跟着超类的更新而发展。除非超类是专门为扩展而设计的，并且具有很好的说明文档。

 

    那么继承回来带什么不安定因素呢？书中第62-65页（潘爱民的中译版，下同）给出了一个扩展HashSet的例子，由于篇幅问题，这里就不摘抄了。

 

    从本条的题目看，是有一种叫做复合的技术，更适合。事实上，书中的例子正是举出继承的脆弱性，又给出使用复合的处理方法。其实，所谓复合就是在原来的“子类”中，不再继承“超类”，而是声明一个私有的域，并使用“超类”类型。

 

    我在以前的帖子中，也曾在讨论“自造控件”时提到过 继承 与 复合（http://bbs.airia.cn/FLEX/thread-2978-1-1.aspx）。那时候我给它们分别起了个非常具有比喻意味的别名——改装 和 组装。是以汽车为例的，比如我们要给一辆量产车上加上一个大号的尾翼（最近由于飞车党撞人事件，网络上都在声讨非法改装，与本例无关，我这里只是举个例子，最终要说明的还是编程技术问题），我们可以理解为以原来的车为基础，在基础之上为了扩展更能而加装了尾翼；另一种思维方式，我们也可以理解为我们是在“制造”一辆赛车，用了两个“零件”，一个是一辆量产车，另一个是赛车尾翼。

 

    这两种“思路”反应在程序上，就是 继承 与 复合 的关系。按照本条的“精神”，如果可以用复合实现，那么就该优先使用复合，而不是继承。从自造Flex控件的工程中，我的一点体会来看，我感觉Flex的控件既不是转为继承而设计的（那些控件的超类除外），也并不明确禁止你去扩展。而在实际中确实发现，如果你不能完全读懂并驾驭原控件的源码，并能很好的改写所有你该改写的方法，那么使用继承确实是一件很危险的事情。比如我就遇到了无法扩展原控件的显示区域的问题。稳妥的办法就是使用复合，当然也会带来一些小麻烦，就如同本条中例子（书第65页）一样也会遇到这样的事情，就是如果你想将原控件（“超类”，例中的HashSet）中的公有成员依然暴露出来的话，就必须逐一为它们写getter方法。

 

 

 

【Effective Java 学习笔记】系列连载专题请见:
http://tonylian.iteye.com/categories/64208