Java：设计类的继承关系时的技巧

继承设计的技巧：

（1）将公共操作和域放置在超类

（2）不要使用受保护的域

有些程序员认为，将大多数的实例域定义为protected是一个不错的主意，只有这样，子类才能够在需要的时候直接访问他们。然而，protected 机制并不能够带来更好的保护，其原因主要有两点。第一，子类集合是无限制的，任何一个人都能够由某个类派生一个子类，并编写代码以直接访问 protected的实例域，从而破坏了封装性。第二，在Java程序设计语言中，在同一个包中的所有类都可以访问protected域，而不管它是否为 这个类的子类。

（3）使用继承实现“is-a”关系

使用继承很容易得到节省代码的目的，但有时候也被人们滥用了。例如，假设需要定义一个钟点工(Contractor)类。钟点工的信息包含姓名和雇佣日 期，但是没有薪水。他们按小时计薪，并且不会因为拖延时间而获得加薪。这似乎在诱导人们由Employee派生出子类Constractor，然后再增加 一个hourlyWage域。

class Contractor extends Employee

{

….

private double hourlyWage;

}

这并不是一个好主意。因为这样一来，每个钟点工对象中都包含了薪水和计时工资这两个域。在实现打印支票或税单方法的时候，会到来无尽的麻烦，并且会多些很多代码。

钟点工与雇员之间不属于“is-a”关系。钟点工不是特殊的雇员。

（4）除非所有继承的方法都有意义，否则不要使用继承。

假设想编写一个Holiday类。毫无疑问，每个假日也是一日，并且一日可以用GregorianCalendar类的实例表示，因此可以使用继承。

class Holiday extends GregorianCalendar

{

………….

}

很遗憾，在继承的操作中，假日集不是封闭的。在GregorianCalendar中有一个共有方法add，可以将假日转换成非假日：

Holiday Christmas;

christmas.add(Calendar.DAY_OF_MONTH,12);

因此，继承对于这个例子来时并不太适宜。

（5）在覆盖方法的时候，不要改变预期的行为。

置换原则不仅应用于语法，而且也可以应用于行为，这似乎更加重要。在覆盖一个方法的时候，不应该毫无缘由的改变行为的内涵。就这一点而言，编译器不会提供 任何帮助，即编译器不会检查重定义的方法是否有意义。例如，可以重定义Holiday类中的add方法“修正”原方法的问题，或什么也不做，或抛出一个异 常，或继续到下一个假日。然而这些都违反了置换原则，语句序列

int d1=x.get(Calendar.DAY_OF_MONTH);

x.add(Calendar.DAY_OF_MONTH,1);

int d2=x.get(Calendar.DAY_OF_MONTH);

System.out.println(d2-d1);

不管x属于GregorianCalendar类，还是属于Holiday类，执行上述语句后都应该得到预期的行为。

当然，这样可能会引起某些争议。人们可能就预期行为的含义争论不休。例如，有些人争论说，置换原则要求Manager.equals不处理bonus域， 因为Employee.equals没有它。实际上，凭空讨论这些问题毫无意义。关键在于，在覆盖子类中的方法时，不要偏离最初的实际想法。

（6）使用多态，而非类型信息。

无论什么时候，对于下面这种形式的代码：

if(x is of type1)

action1(x);

else if (x is of type2)

action2(x)

都应该考虑使用多态性。

action1与 action2表示的是相同的概念吗？如果是相同的概念，就应该为这个概念定义一个方法，并将其放置在两个类的超类或接口中，然后，就可以调用x.action( );以便使用多态性提供的动态分派机制执行相应的动作。

使用多态犯法或接口编写的代码比使用对多种类型进行检测的代码更加易于为何和扩展。

（7）不要过多地使用反射

反射机制使得人们可以通过在运行时查看域和方法，让人们编写出更具有通行的程序。这种功能对于编写系统程序来说及其实用，但是通常不是用于编写应用程序。反射是很脆弱的，即编译器很难帮助人们发现程序中的错误。任何错误只能在运行时才被发现，并导致异常。