【IT168 技术文章】程序中除了最无关紧要的部分外都要对某些数据类型进行操作。静态类型系统提供了一种方法，它能够确保程序不会对给定类型的数据进行不当的操作。Java 语言的优点之一是严格的区分类型，所以在程序运行前已消除了类型错误。作为开发人员，我们可以使用这个类型系统提供更健壮且没有错误的代码。然而，我们却常常没有让类型系统发挥出最大的潜力。
Impostor Type 错误模式
很多程序可以更多地使用静态类型系统，但它们没有这样做，而是依赖包含区别数据类型标记的特殊字段。
依靠这些特殊字段区别数据类型，这样的程序放弃了类型系统专门提供给它们的保护措施。当这些标记中的一个对它的数据误贴了标签，就会产生我称之为 Impostor Type的错误。
症状
impostor type 错误的一种常见症状是很多概念上不同类型的数据都被同样(并且错误)的方式处理。另一常见症状是数据与任何指定的类型都不匹配。
首要规则是，只要当概念上的数据类型和它被程序处理的方法不匹配，就可以怀疑是否发生了这个模式的错误。
为说明引入这种模式的错误是多么的轻而易举，让我们来考虑一个简单的示例。假设我们需要处理各种各样的欧几里得几何学形状，如圆形、正方形等等。这些几何形状没有坐标，但含有一个 scale 变量，所以可以计算它们的面积。
清单 1. 用 imposter type 实现各种几何形状
2 String shape;
3 double scale;
4 public Form(String _shape, double _scale) {
5 this.shape = _shape;
6 this.scale = _scale;
7 }
8 public double getArea() {
9 if (shape.equals("square")) {
10 return scale * scale;
11 }
12 else if (shape.equals("circle")) {
13 return Math.PI * scale * scale;
14 }
15 else { // shape.equals("triangle"), an equilateral triangle
16 return scale * (scale * Math.sqrt(3) / 4);
17 }
18 }
19 }
20
尽管您会发现人们经常这么做，但用这种方法实现几何形状还是存在严重缺点。
最显著的缺点之一是这个方法不能真正的扩展。如果要为我们的 form 引入一个新的几何形状(比如，“五边形”)，我们必须进入并修改 getArea() 方法的源代码。不过可扩展性是个独立的考虑因素;在本文中，我们把重点放在实现几何形状所造成的错误的易受性上。我会在以后的文章中回到关于可扩展性的问题上来。
如果我们在程序其它部分构造了一个新的 Form 对象，如下所示，请考虑将会发生什么情况：
清单 2. 构造一个新的 form
2
当然，“square”被拼错了，但是编译器认为，这是完全合法的代码。
现在考虑一下，当我们试图对新的 Form 对象调用，比如说 getArea() 方法时发生什么情况。因为 Form 对象中的几何形状与 if-then-else代码块中的任一测试的几何形状都不匹配，它的面积将在 else分句中被计算，好像它是个三角形似的!
这里将不会报错。事实上，在很多情况下，返回值看起来都好象是完全合理的数字。即使我们插入些冗余代码，检查 else分句中的隐含条件是否包含(比如说，断言)，也要到代码执行时才能发现错误。
很多其它相似的错误也可能在上述代码中产生。 if-then-else 代码块可能会偶尔遗漏一句分句，导致类型与那句分句相对应的所有 Form 都被错误地处理了。此外，因为 impostor type 在字段中只是一个 String ，所以它可能会被意外或恶意地修改。
无论用哪一种方法，这样的修改会带来各种各样的损害。
治疗和预防措施
正如您可能设想过的那样，我建议用类型系统在静态检查期间将它们清除，从而避免这种类型的错误。请考虑这种新颖的实现方法：
清单 3. 用实际类型实现 form
2 double scale;
3 public Form(double _scale) {
4 this.scale = _scale;
5 }
6 public abstract double getArea();
7 }
8 class Square extends Form {
9 public Square(double _scale) {
10 super(_scale);
11 }
12 public double getArea() {
13 return scale * scale;
14 }
15 }
16 class Circle extends Form {
17 public Circle(double _scale) {
18 super(_scale);
19 }
20 public double getArea() {
21 return Math.PI * scale * scale;
22 }
23 }
24 class Triangle extends Form {
25 public Triangle(double _scale) {
26 super(_scale);
27 }
28 public double getArea() {
29 return scale * (scale * Math.sqrt(3) / 4);
30 }
31 }
32
现在考虑一下，在创建一个新 Form 时，如果误输入了“Sqaure”，会发生什么情况。编译器将会报错，告诉我们类 Sqaure 找不到。代码将连运行的机会也没有。
同样地，编译器将不会允许我们忘记为我们的任意子类定义 getArea() 方法。当然，任何对象要改变 Form 的类型是不可能的。
最后说明
在离开这个主题之前，我还想讨论另一种可能的实现，一种我曾经讨论过的两种实现方法的混合。
在这种情况下，不使用 impostor type，但代码包含很多相同的易受性，似乎它们以前就有。实际上，这种实现方法比对每个类型单独实现 getArea() 方法 更差。
清单 4. 一种混合的实现方式
2 double scale;
3 public Form(double _scale) {
4 this.scale = _scale;
5 }
6 public double getArea() {
7 if (this instanceof Square) {
8 return scale * scale;
9 }
10 else if (this instanceof Circle) {
11 return Math.PI * scale * scale;
12 }
13 else { // this instanceof Triangle
14 return scale * (scale * Math.sqrt(3) / 4);
15 }
16 }
17 }
18 class Square extends Form {
19 public Square(double _scale) {
20 super(_scale);
21 }
22 }
23 class Circle extends Form {
24 public Circle(double _scale) {
25 super(_scale);
26 }
27 }
28 class Triangle extends Form {
29 public Triangle(double _scale) {
30 super(_scale);
31 }
32 }
33
尽管编译器仍旧会捕获类型的拼写错误，且对象类型是无法改变的，我们又一次使用了 if-then-else代码块调度适当的类型。这样，我们又要面临 if-then-else代码块中 instanceof检查与我们所操作的那组类型不匹配的情况。
还必须提出，像第一种实现方法那样，这个实现方法的扩展性不如第二种。
总结
那么，简而言之，这就是我们最近的错误模式：
模式：Impostor Type
症状：一种程序，它用同样的方式处理概念上不同类型的数据，或者无法识别某种类型的数据。
起因：程序针对各种类型的数据使用带标记的字段，而不是独立的类。
治疗和预防措施：尽可能将概念上不同的数据类型分成几个独立的类。
