选择Java接口还是抽象类

选择Java接口还是抽象类
　　
　　作者：俞良松 本文选自：开放系统世界－赛迪网 2003年03月12日
　　
　　　　很多人有过这样的疑问：为什么有的地方必须使用接口而不是抽象类，而在另一些地方，又必须使用抽象类而不是接口呢？或者说，在考虑Java类的一般化问题时，很多人会在接口和抽象类之间犹豫不决，甚至随便选择一种。
　　
　　　　实际上接口和抽象类的选择不是随心所欲的。
　要理解接口和抽象类的选择原则，有两个概念很重要：对象的行为和对象的实现。如果一个实体可以有多种实现方式，则在设计实体行为的描述方式时，应当达到这样一个目标：在使用实体的时候，无需详细了解实体行为的实现方式。也就是说，要把对象的行为和对象的实现分离开来。既然Java的接口和抽象类都可以定义不提供具体实现的方法，在分离对象的行为和对象的实现时，到底应该使用接口还是使用抽象类呢？
　　
　　通过抽象类建立行为模型
　　
　　　　在接口和抽象类的选择上，必须遵守这样一个原则：行为模型应该总是通过接口而不是抽象类定义。为了说明其原因，下面试着通过抽象类建立行为模型，看看会出现什么问题。
　　
　　　　假设要为销售部门设计一个软件，这个软件包含一个“发动机”（Motor）实体。显然无法在发动机对象中详细地描述发动机的方方面面，只能描述某些对当前软件来说重要的特征。至于发动机的哪些特征是重要的，则要与用户（销售部门）交流才能确定。
　　
　　　　销售部门的人要求每一个发动机都有一个称为马力的参数。对于他们来说，这是惟一值得关心的参数。基于这一判断，可以把发动机的行为定义为以下行为。
　　
　　　　行为1：查询发动机的马力，发动机将返回一个表示马力的整数。
　　
　　　　虽然现在还不清楚发动机如何取得马力这个参数，但可以肯定发动机一定支持这个行为，而且这是所有发动机惟一值得关注的行为特征。这个行为特征既可以用接口定义，也可以用抽象类定义。为了说明用抽象类定义可能出现的问题，下面用抽象类建立发动机的行为模型，并用Java方法描述行为1，代码如下：
　　
　　
　　
　　public abstract Motor{
　　
　　abstract public int getHorsepower();
　　
　　}
　　
　　
　　
　　　　在Motor抽象类的基础上构造出多种具体实现，例如A型发动机、B型发动机等，再加上系统的其它部分，最后得到1.0版的软件并交付使用。一段时间过去了，现在要设计2.0版的软件。在评估2.0版软件需求的过程中，发现一小部分发动机是电池驱动的，而电池需要一定的充电时间。销售部门的人希望能够通过计算机查阅充电时间。根据这一要求定义一个新的行为，如图1所示。