接口和抽象类的选择不是随心所欲的
要理解接口和抽象类的选择原则,有两个概念很重要:对象的行为和对象的实现
如果一个实体有多种实现方式,则在设计实体行为的描述方式时,应当是在使用实体的时候,无需详细了解实体行为的实现方式.就是要把对象的行为和对象的实现分离开来
既然Java的接口和抽象类都可以定义不提供具体实现的方法,在分离对象的行为和对象的实现时,使用接口还是使用抽象类就有待商榷.
抽象类建立行为模型;在接口和抽象类的选择上,必须遵守一个原则:行为模型应该总是通过接口而不是抽象类定义.
为了说明其原因,下面试着通过抽象类建立行为模型,看看会出现什么问题.
假设要为销售部门设计一个软件,这个软件包含一个"发动机"(Motor)实体.显然无法在发动机对象中详细地描述发动机的方方面面,只能描述某些对当前软件来说重要的特征.至于发动机的哪些特征是重要的,则要与用户(销售部门)交流才能确定.销售部门的人要求每一个发动机都有一个称为马力的参数,对于他们来说,这是惟一值得关心的参数.基于这一判断,可以把发动机的行为定义为以下行为。
行为1:查询发动机的马力,发动机将返回一个表示马力的整数;虽然还不清楚发动机如何取得马力参数,但可以肯定发动机一定支持这个行为,而且这是所有发动机惟一值得关注的行为特征.[b][color=red]这个行为特征既可以用接口定义,也可以用抽象类定义.[/color][/b]
为了说明用抽象类定义可能出现的问题,下面用抽象类建立发动机的行为模型,并用Java方法描述行为1,代码如下:
在Motor抽象类的基础上构造出多种具体实现,例如A型发动机,B型发动机等,再加上系统的其它部分,最后得到1.0版的软件并交付使用.一段时间过去,要设计2.0版的软件
在评估2.0版软件需求的过程中,发现一小部分发动机是电池驱动的,而电池需要一定的充电时间.销售部门的人希望能够通过计算机查阅充电时间.
根据这一要求定义新的行为;行为2:查询电驱动发动机的充电时间,发动机将返回一个表示充电时间的整数. 用Java方法来描述这个行为,代码如下:
在销售部门的软件中,电驱动发动机也以类的形式实现,但这些类从BatteryPoweredMotor而不是Motor派生.这些改动加入到2.0版软件之后,销售部门很满意.随着业务的不断发展,不久之后光驱动的发动机出现了.销售部门要求光驱动发动机需要一定光能才能运转,光能以流明(Lumen)度量.这个信息对客户很重要,因为下雨或多云的天气里,某些光驱动发动机可能无法运转.
销售部门要求为软件增加对光驱动发动机的支持,所以要定义一个新的行为.
行为3:查询光驱动发动机能够正常运转所需要的最小流明数,发动机返回一个整数
再定义一个抽象类并把行为3转换成Java方法,代码如下:
[img]http://software.ccidnet.com/col/attachment/2003/3/112835.jpg[/img]
如图1所示,SolarPoweredMotor和BatteryPoweredMotor都从Motor抽象类派生.
在整个软件中,90%以上的代码以相同的方式对待所有的发动机.偶尔需要检查一下发动机是光驱动还是电驱动,使用instanceof实现,代码如下:
无论是哪种发动机,马力这个参数都很重要,所以在所有派生的抽象类(SolarPoweredMotor和BatteryPoweredMotor)中,getHorsepower()方法都有效.
现在销售部门又有了一种新的发动机,它是一种既有电驱动又有光驱动的双重驱动发动机.
光驱动和电驱动的行为本身没有变化,但新的发动机同时支持两种行为.在考虑如何定义新型的光电驱动发动机时,接口和抽象类的差别开始显示出来了.新的目标是在增加新型发动机的前提下尽量少改动代码.因为与光驱动发动机、电驱动发动机有关的代码已经过全面的测试,不存在已知的Bug.为了增加光电驱动发动机,要定义新的SolarBatteryPowered抽象类。
如果让SolarBatteryPowered从Motor抽象类派生,SolarBatteryPowered将不支持针对光驱动发动机和电驱动发动机的instanceof操作.也就是说,如果查询一个光电驱动的发动机是光驱动的,还是电驱动的,得到的答案是:都不是.如果让SolarBatteryPowered从SolarPoweredMotor(或BatteryPoweredMotor)抽象类派生,SolarBatteryPowered将不支持针对BatteryPoweredMotor(或SolarPoweredMotor)的instanceof操作.
从行为上看,光电驱动的发动机必须同时从两个抽象类派生,但Java语言不允许多重继承.
之所以会出现这个问题,根本的原因在于使用抽象类不仅意味着定义特定的行为,而且意味着定义实现的模式.也就是说,应该定义发动机如何获得行为的模型,而不仅仅是声明发动机具有某一个行为
通过接口建立行为模型;如果用接口来建立行为模型,就可以避免隐含地规定实现模式.
例如前面的几个行为改用接口定义如下
行为1:
行为2:
行为3:
public interface SolarPoweredMotor extends Motor{
abstract public int getLumensToOperate();
}
现在光电驱动的发动机可以描述为:
[img]http://software.ccidnet.com/col/attachment/2003/3/112836.jpg[/img]
DualPoweredMotor只继承行为定义,而不是行为的实现模式,如图2所示。
[b][color=blue]在使用接口的同时仍旧可以使用抽象类,不过这时抽象类的作用是实现行为,而不是定义行为.只要实现行为的类遵从接口定义,即使它改变了父抽象类,也不用改变其它代码与之交互的方式.特别是对于公用的实现代码,抽象类有它的优点.抽象类能够保证实现的层次关系,避免代码重复.然而,即使在使用抽象类的场合,也不要忽视通过接口定义行为模型的原则.
从实践的角度来看,如果依赖于抽象类来定义行为,往往导致过于复杂的继承关系,而通过接口定义行为能够更有效地分离行为与实现,为代码的维护和修改带来方便.[/color][/b]
要理解接口和抽象类的选择原则,有两个概念很重要:对象的行为和对象的实现
如果一个实体有多种实现方式,则在设计实体行为的描述方式时,应当是在使用实体的时候,无需详细了解实体行为的实现方式.就是要把对象的行为和对象的实现分离开来
既然Java的接口和抽象类都可以定义不提供具体实现的方法,在分离对象的行为和对象的实现时,使用接口还是使用抽象类就有待商榷.
抽象类建立行为模型;在接口和抽象类的选择上,必须遵守一个原则:行为模型应该总是通过接口而不是抽象类定义.
为了说明其原因,下面试着通过抽象类建立行为模型,看看会出现什么问题.
假设要为销售部门设计一个软件,这个软件包含一个"发动机"(Motor)实体.显然无法在发动机对象中详细地描述发动机的方方面面,只能描述某些对当前软件来说重要的特征.至于发动机的哪些特征是重要的,则要与用户(销售部门)交流才能确定.销售部门的人要求每一个发动机都有一个称为马力的参数,对于他们来说,这是惟一值得关心的参数.基于这一判断,可以把发动机的行为定义为以下行为。
行为1:查询发动机的马力,发动机将返回一个表示马力的整数;虽然还不清楚发动机如何取得马力参数,但可以肯定发动机一定支持这个行为,而且这是所有发动机惟一值得关注的行为特征.[b][color=red]这个行为特征既可以用接口定义,也可以用抽象类定义.[/color][/b]
为了说明用抽象类定义可能出现的问题,下面用抽象类建立发动机的行为模型,并用Java方法描述行为1,代码如下:
public abstract Motor{
abstract public int getHorsepower();
}
在Motor抽象类的基础上构造出多种具体实现,例如A型发动机,B型发动机等,再加上系统的其它部分,最后得到1.0版的软件并交付使用.一段时间过去,要设计2.0版的软件
在评估2.0版软件需求的过程中,发现一小部分发动机是电池驱动的,而电池需要一定的充电时间.销售部门的人希望能够通过计算机查阅充电时间.
根据这一要求定义新的行为;行为2:查询电驱动发动机的充电时间,发动机将返回一个表示充电时间的整数. 用Java方法来描述这个行为,代码如下:
public abstract BatteryPoweredMotor extends Motor{
abstract public int getTimeToRecharge();
}
在销售部门的软件中,电驱动发动机也以类的形式实现,但这些类从BatteryPoweredMotor而不是Motor派生.这些改动加入到2.0版软件之后,销售部门很满意.随着业务的不断发展,不久之后光驱动的发动机出现了.销售部门要求光驱动发动机需要一定光能才能运转,光能以流明(Lumen)度量.这个信息对客户很重要,因为下雨或多云的天气里,某些光驱动发动机可能无法运转.
销售部门要求为软件增加对光驱动发动机的支持,所以要定义一个新的行为.
行为3:查询光驱动发动机能够正常运转所需要的最小流明数,发动机返回一个整数
再定义一个抽象类并把行为3转换成Java方法,代码如下:
public abstract SolarPoweredMotor extends Motor{
abstract public int getLumensToOperate();
}
[img]http://software.ccidnet.com/col/attachment/2003/3/112835.jpg[/img]
如图1所示,SolarPoweredMotor和BatteryPoweredMotor都从Motor抽象类派生.
在整个软件中,90%以上的代码以相同的方式对待所有的发动机.偶尔需要检查一下发动机是光驱动还是电驱动,使用instanceof实现,代码如下:
if (instanceof SolarPoweredMotor){...}
if (instanceof BatteryPoweredMotor){...}
无论是哪种发动机,马力这个参数都很重要,所以在所有派生的抽象类(SolarPoweredMotor和BatteryPoweredMotor)中,getHorsepower()方法都有效.
现在销售部门又有了一种新的发动机,它是一种既有电驱动又有光驱动的双重驱动发动机.
光驱动和电驱动的行为本身没有变化,但新的发动机同时支持两种行为.在考虑如何定义新型的光电驱动发动机时,接口和抽象类的差别开始显示出来了.新的目标是在增加新型发动机的前提下尽量少改动代码.因为与光驱动发动机、电驱动发动机有关的代码已经过全面的测试,不存在已知的Bug.为了增加光电驱动发动机,要定义新的SolarBatteryPowered抽象类。
如果让SolarBatteryPowered从Motor抽象类派生,SolarBatteryPowered将不支持针对光驱动发动机和电驱动发动机的instanceof操作.也就是说,如果查询一个光电驱动的发动机是光驱动的,还是电驱动的,得到的答案是:都不是.如果让SolarBatteryPowered从SolarPoweredMotor(或BatteryPoweredMotor)抽象类派生,SolarBatteryPowered将不支持针对BatteryPoweredMotor(或SolarPoweredMotor)的instanceof操作.
从行为上看,光电驱动的发动机必须同时从两个抽象类派生,但Java语言不允许多重继承.
之所以会出现这个问题,根本的原因在于使用抽象类不仅意味着定义特定的行为,而且意味着定义实现的模式.也就是说,应该定义发动机如何获得行为的模型,而不仅仅是声明发动机具有某一个行为
通过接口建立行为模型;如果用接口来建立行为模型,就可以避免隐含地规定实现模式.
例如前面的几个行为改用接口定义如下
行为1:
public interface Motor(){
public int getHorsepower();
}
行为2:
public interface BatteryPoweredMotor extends Motor(){
public int getTimeToRecharge();
}
行为3:
public interface SolarPoweredMotor extends Motor{
abstract public int getLumensToOperate();
}
现在光电驱动的发动机可以描述为:
public DualPoweredMotor implements SolarPoweredMotor,BatteryPoweredMotor{}
[img]http://software.ccidnet.com/col/attachment/2003/3/112836.jpg[/img]
DualPoweredMotor只继承行为定义,而不是行为的实现模式,如图2所示。
[b][color=blue]在使用接口的同时仍旧可以使用抽象类,不过这时抽象类的作用是实现行为,而不是定义行为.只要实现行为的类遵从接口定义,即使它改变了父抽象类,也不用改变其它代码与之交互的方式.特别是对于公用的实现代码,抽象类有它的优点.抽象类能够保证实现的层次关系,避免代码重复.然而,即使在使用抽象类的场合,也不要忽视通过接口定义行为模型的原则.
从实践的角度来看,如果依赖于抽象类来定义行为,往往导致过于复杂的继承关系,而通过接口定义行为能够更有效地分离行为与实现,为代码的维护和修改带来方便.[/color][/b]