第20条:类层次优于标签类
有时候,可能会遇到带有两个甚至更多风格的实例的类,并包含表示实例风格的标签(tag)域。
class Figure {
enum Shape { RECTANGLE, CIRCLE };
// Tag field - the shape of this figure
final Shape shape;
// These fields are used only if shape is RECTANGLE
double length;
double width;
// This field is used only if shape is CIRCLE
double radius;
// Constructor for circle
Figure(double radius) {
shape = Shape.CIRCLE;
this.radius = radius;
}
// Constructor for rectangle
Figure(double length, double width) {
shape = Shape.RECTANGLE;
this.length = length;
this.width = width;
}
double area() {
switch(shape) {
case RECTANGLE:
return length * width;
case CIRCLE:
return Math.PI * (radius * radius);
default:
throw new AssertionError();
}
}
}
这种标签类(tagged class)有着许多的缺点。他们之中充斥着样板代码,包括枚举声明、标签域以及条件语句。由于多个实现乱七八糟的挤在了单个类中,破坏了可读性。内存的占用也
增加了,因为实例承担着属于其他风格的不相干域。一句话,标签类过于冗长、容易出错,并且效率低下。
幸运的是,面向对象语言例如Java,都提供了其他更好的方法来定义能表示多种风格对象的单个数据类型:子类型化。标签类正是类层次的一种简单的仿效。
abstract class Figure {
abstract double area();
}
class Circle extends Figure {
final double radius;
Circle(double radius) { this.radius = radius; }
double area() { return Math.PI * (radius * radius); }
}
class Rectangle extends Figure {
final double length;
final double width;
Rectangle(double length, double width) {
this.length = length;
this.width = width;
}
double area() { return length * width; }
}
这个类层次纠正了前面提到的标签类的所有缺点。这段带啊简单且清楚,没有包含在原来版本中所见到的所有样板代码。每个类型的实现都是自己的类,这些类都没有受到不相关域的拖累。所有的域都是final的。编译器确保每个类的构造方法都初始化它的数据域,对于根类中声明的抽象方法,都确保有个实现。这样就杜绝了由于遗漏switch case而导致的运行时失败的可能。
类层次的另一个好处在于,他们可以用来反映类之间本质上的层次关系,有助于增强灵活性,并进行更好的编译时类型检查。假设上述例子中的标签类也允许表达正方形。类层次可以反映正方形是一种特殊的矩形这一事实(假设两者都是不可变的):
class Square extends Rectangle {
Square(double side) {
super(side, side);
}
}
注意,上述层次中的域是被直接访问的,而不是通过访问方法。这是为了简洁起见才这样做的,如果层次结构是公有的,则不允许这样做。
简而言之,标签类很少有适用的时候。当你想要编写一个包含显示标签域的类时,应该考虑一下,这个标签是否可以被取消,这个类是否可以用类层次来代替。当你遇到一个包含标签的现有类时,就要考虑将它重构到一个层次结构中去。