防止到 String 类的不恰当的类型转换
充分利用 Java 语言多态性
级别：中级
Fernando Ribeiro（[email protected]）
顾问
2002 年 10 月
字符串化是从对象到字符串的转换，而对于本文，错误的字符串化是指对 String 类的不恰当的类型转换。例如，本文中的示例将向您展示产品代码很少是字符串，但许多开发人员会将其类型转换为 String 类，因而将危及面向对象编程中的多态性的广泛用途。
尽管看起来只是样式问题（因为错误字符串化“错误模式”的一个隐蔽属性就是：它在任何时候（即使是测试时）都不引起任何错误），但避免对 String 类进行不恰当的类型转换可以使您充分利用 Java 语言内在的多态性特性。在实践方面，避免这种模式是防止它的最佳方法，而避免它的最佳方法是为您代码中的大多数元素定义一个特定的类型。通过这样做，您确保了每个类的类型适合于其任务，从而确保了系统的可靠性。这个解决方案会对您的系统性能增加一些开销，但换来的是一个可靠得多的系统。
在本文中，我们将在企业系统环境中讨论这个模式，并且将研究一种检测这种错误的方法：方法的错误重载。（我们不会在本文中过多地讨论修改错误，因为，简单地避免使用字符串表示是解决该问题最佳和最常见的方法。）
聚焦 String 不恰当的类型转换
我喜欢和研究错误模式一样来研究不恰当地将类型转换为 String 类这一问题。因此，让我们将这种问题称为错误字符串化错误模式。（有关错误模式的更多信息，请参阅参考资料中 Eric Allen 的诊断 Java 代码专栏文章。）
UML（统一建模语言）：通过制定计划或“蓝图”来简化软件设计过程，以此来明确说明、可视化、构造和文档化软件系统构件的语言。
OCL（对象约束语言）：统一建模语言（UML）的表达语言；它具有纯表达语言（不能更改模型中的任何东西）、建模语言（所有实现问题均超出范围并无法表达）和形式语言（所有构造都有形式定义的意义）的特征。
类型安全的、类型安全：指定类型的 UML 模型元素（如字段或操作），其结构和行为最贴切地符合元素规范。
字符串化：将对象转换成字符串。
多态性：在面向对象编程中，编程语言根据对象的类型以不同方式处理它们的能力。
方法重载：在面向对象应用程序中重新定义派生类的方法的能力，其中方法名称保持相同，但参数的类型更改了。
在我们继续讨论之前，请允许我迅速讨论一下类型安全的概念。当 UML 模型元素是类型安全的时，其结构和行为贴切地与其规范相匹配，或者换句话说，它是明确地为其用途开发的。有助于您理解的示例是：搜索索引列表的操作的“键”参数不是一个字符串，而只是一个对象，类似于其它 Java 对象，可以通过调用 toString() : String 方法将它字符串化。差异在于字符串可以求子字符串、连接等；但键不能。它们是键，不是字符串。
在类型安全的应用程序中，color 字段的类型、getColor(): String 方法的返回类型和 setColor(color : String) : void 方法的 color 参数的类型都是 Color 而不是 String — 它返回车辆的颜色而不是其字符串表示。清单 1 提供了示例。
在本文的代码示例中，我们将使用一个假想的企业系统，该系统包括汽车工业产品的运输和跟踪功能。我们将为这个系统定义类，包括 Vehicle 类（当我们讨论单个车辆细节时使用）和更普通的 Product 类（作为一般企业产品目录的示例）。
清单 1. 错误字符串化的车辆
/** * The vehicle **/ public class Vehicle { /** * Construct a vehicle **/ public Vehicle() { } /** * The color of a vehicle **/ private String color; /** * Get the color of a vehicle * @return The color of a vehicle **/ public String getColor() { return this.color; } /** * Set the color of a vehicle * @param color A color **/ public void setColor(String color) { this.color = color; } }
这种错误模式出现在许多企业系统（包括产品目录）中。研究下列代码以获得示例（这个示例也定义了 Product 类）：
清单 2. 错误字符串化的产品
/** * The product **/ public class Product { /** * Construct a product **/ public Product() { } /** * Construct a product * @param code A code **/ public Product(String code) { this.setCode(code); } /** * The code of a product **/ private String code; public boolean equals(Object b) { if (!(b instanceof Product)) return false; return this.getCode().equals(((Product)b).getCode()); } protected void finalize() { this.setCode(null); } /** * Get the code of a product * @return The code of a product **/ public String getCode() { return this.code; } public int hashCode() { String code = this.getCode(); // defensively copies if (code == null) return 0; return code.hashCode(); } /** * Set the code of a product * @param code A code **/ public void setCode(String code) { this.code = code; } public String toString() { return new String(); } }
关于上述代码中 Product 类设计的几点注释：
第一个构造函数是空的并且不获取任何参数。 第二个构造函数获取一段代码。 这些代码组成（属于）产品。 产品的字符串表示是空字符串。 产品按其代码来比较是否相等。 产品的散列码是其代码的散列码。让我们研究一下用于最后两项的一些代码示例。
产品按其代码来比较是否相等
以下是说明这一点的 OCL 约束：
context Product::equals(b : Object) : boolean pre: b.oclIsKindOf(Product); post: result = self.getCode().equals(b.oclAsType(Product).getCode());
产品及其代码的散列码相同
以下是说明这一点的 OCL 约束：
context Product::hashCode() : int post: let code : String = self.getCode() in if code.oclIsUndefined() then result = 0; else result = code.hashCode(); end if
以下是发生错误字符串化错误模式能够削弱您产生良好代码的能力的原因 — 产品代码不是字符串，因为它所需要的结构和行为可能超出 String 类所允许的范围。
（本文中 OCL 约束是基于 OCL 2.0 建议的 — 例如，在 OCL 1.4 中不存在“oclIsNew”。有关 OCL 的更多信息，请参阅参考资料。）
产品代码还可能需要专门化（如销售或工程产品代码）。并且某些产品可能被多次编码 — 工程代码可能被用于后勤系统；后勤代码可能被用于销售系统；工程、后勤和销售代码都可能被用于电子商务系统。产品代码的用法需求有几分象指挥开发人员的红旗，把他们引向为每种产品代码开发新的特定类型的方法。
那么为什么会发生这种问题呢？而我们又应该如何修正或避免它？
问题和一些解决方案
问题之所以会发生，是因为大多数程序员没有在面向对象应用程序中利用类型安全。（请记住，我们认为值得另外花一些力气去定义一个特定于需求的新类型而不是依靠现有的类型，因为现有类型可能不够匹配并可能引起问题。）下列车辆问题尝到了类型安全应用程序的甜头，其中车辆（轿车和卡车）是由不同的船运输的。请研究下列代码：
/** * Deliver a vehicle * @param vehicle A vehicle **/ public void deliver(String vehicle) { // is it a car or a truck? }
deliver(vehicle : String) : void 方法实现了字符串的传递（令人沮丧但事实如此）而不是车辆的传递，因为任何字符串都可以指定给 vehicle 参数。这实际上不是该问题的解决方案。
对于我们希望调用程序传递给该方法的类型来说，Vehicle 类型（类似于下一个代码块中使用的类型）是好得多的匹配类型。
/** * Deliver a vehicle * @param vehicle A vehicle **/ public void deliver(Vehicle vehicle) { // who delivers a vehicle? }
deliver(vehicle:Vehicle) : void 方法实现了车辆的传输，但是，因为轿车和卡车（这个环境中的所有车辆）是用不同的船运输的，所以它也不是该问题的完整解决方案。
研究下面的这些代码：
/** * Deliver a car * @param car A car **/ public void deliverCar(String car) { // delivered by the first ship } /** * Deliver a truck * @param truck A truck **/ public void deliverTruck(String truck) { // delivered by the second ship }
这也不是好的解决方案，因为这种方法要求 deliverCar(car : String) : void 和 deliverTruck(truck: String) : void 方法的调用程序按条件对轿车和卡车区别对待。
最后，研究下列代码：
/** * Deliver a car * @param car A car **/ public void deliver(Car car) { // delivered by the first ship } /** * Deliver a truck * @param truck A truck **/ public void deliver(Truck truck) { // delivered by the second ship }
这种方法不要求 deliver(car : Car) : void 和 deliver(truck : Truck) : void 方法的调用程序按条件对轿车和卡车区别对待，因为方法重载允许开发人员为几种参数列表实现相同行为。这种方法适合于面向对象应用程序。
迄今为止，我们讨论的代码示例已经使用了方法重载和 Java 编译器中的特性 — 方法削窄，方法削窄搜索调用程序请求的操作的最佳匹配。这种搜索不仅取决于方法名称，而且取决于其参数类型和参数列表的大小。（有关方法削窄的更多信息，请参阅参考资料。）
当用同一艘船运输轿车和卡车时，deliver(vehicle : Vehicle) : void 方法取代了 deliver(car : Car) : void 和 deliver(truck : Truck) : void 方法。并且，按照 Java 规范的二进制兼容性原则，这两个方法的调用程序甚至不必重新编译。这就是 Java 应用程序所显示出的多态性的能力。
预防方法
避免字符串化所带来的问题的“金科玉律”是这样的：
下列代码和 UML 类图将演示以 UML 表示的类型安全的面向对象应用程序的清晰设计。
研究类型安全的产品
下列的代码块是一种设计良好的类型安全的产品。
清单 3. 类型安全的产品
/** * The product **/ public class Product { /** * Construct a product **/ public Product() { } /** * Construct a product * @param code A code **/ public Product(ProductCode code) { this.setCode(code); } /** * The code of a product **/ private ProductCode code; public boolean equals(Object b) { if (!(b instanceof Product)) return false; return this.getCode().equals(((Product)b).getCode()); } protected void finalize() { this.setCode(null); } /** * Get the code of a product * @return The code of a product **/ public ProductCode getCode() { return this.code; } public int hashCode() { ProductCode code = this.getCode(); // defensively copies if (code == null) return 0; return code.hashCode(); } /** * Set the code of a product * @param code A code **/ public void setCode(ProductCode code) { this.code = code; } public String toString() { return new String(); } }
图 1. 类型安全的产品的 UML 类图
研究类型安全的产品代码
在本节中，我们将研究产品代码和 ProductCode 类。
清单 4. 产品代码
/** * The product code **/ public class ProductCode { /** * Construct a product code **/ public ProductCode() { } public boolean equals(Object b) { if (!(b instanceof ProductCode)) return false; return this.toString().equals(b.toString()); } public int hashCode() { return this.toString().hashCode(); } public String toString() { return new String(); } }
快速提示：此时，有些开发人员会提问每次调用 toString 都返回一个新的 String 是否明智。我已经和其他开发人员（包括 Effective Java Programming 的作者 Joshua Bloch）证实了这种方法，并且它看起来是目前的最佳解决方案。调用 intern() 来访问这个池会很笨拙，因为保存这个方法的返回值的变量往往是“短命的”，所以认为性能不成问题。
关于 ProductCode 类设计的几点注释：
构造函数是空的并不获取任何参数。 产品按其代码的字符串表示来比较是否相等。 产品代码的散列码是其字符串表示的散列码。 产品代码的字符串表示是空字符串。让我们更仔细地研究最后三项。
产品按其代码的字符串表示来比较是否相等
以下是说明这一点的 OCL 约束：
context ProductCode::equals(b : Object) pre: b.oclIsKindOf(ProductCode) post: result = self.getCode().equals(b.getCode())
产品代码的散列码及其字符串表示的散列码相同
以下是说明这一点的 OCL 约束：
context ProductCode::hashCode() : int post: result = self.toString().hashCode();
产品代码的字符串表示是空字符串
以下是说明这一点的 OCL 约束：
context ProductCode::toString() : String post: result.oclIsNew();
研究接口实现
可以通过 ProductCode 类的子类方便地实现某些接口：
让我们用代码示例说明这些子类接口实现。我们将从 Cloneable 开始：
public Object clone() throws CloneNotSupportedException { return super.clone(); }
以下是 Comparable 接口实现的示例：
public int compareTo(Object b) { if (!(b instanceof ProductCode)) throw new ClassCastException(); return toString().compareTo(b.toString()); }
以下是用 ProductCode 类的子类更改产品代码字符串表示的演示：
ProductCode pc = new ProductCode() { public String toString() { return "9BGRD08Z01G167984"; } };
请注意：上一个示例中语法并不特别完美。
对字符串的一点补充
String 类是 final 类。因为有着非常充分的理由：该类本身已经提供了由 Java 应用程序使用的所有行为，所以它不能被继承。从 String 类继承 ProductCode 类（就象某些开发人员喜欢做的那样），会象使用产品代码的字符串表示而不是产品代码本身来组成产品一样笨拙。
使用类型安全来避免错误字符串化错误模式将花费额外的时间（用来创建新的、更特定的类型），可能不会增加您系统的性能，但会始终增加您系统的可靠性。
多态性的好处和使用类型安全的习惯关系密切，并且错误字符串化是关心这一点以及理解它不仅仅是个样式问题的又一个原因。
我要感谢 OCL 规范的作者和 Klasse Objecten 的 Jos Warmer 和 Anneke Kleppe，他们对本文的写作提供了意见和支持。
参考资料
有关错误模式的更多信息，请参阅 Eric Allen 的诊断 Java 代码专栏。
Granville Miller 的专栏 Java 建模是统一建模语言及其表达语言 OCL 很好的信息来源。
关于 OCL 和 UML 的另外两个优秀的参考资料是来自 Boldsoft、Rational Software Corporation、IONA 和 Adaptive Ltd. 的 UML 1.4 规范和 OCL 2.0 建议，查看它们以了解关于 OCL 的更多内容。
在 IBM OCL 页面上可以找到许多关于 OCL 的内容，包括定义、发展史和到其它参考资料的链接。
IBM OCL Parser 0.3 是一种有用的理解 OCL 的工具。
可以在这篇 Sun 技术文章中找到关于有用的 Java 特性方法削窄的很好的参考资料。
请到 developerWorks Java 技术专区查找其它关于 Java 的参考资料。
本文地址：http://com.8s8s.com/it/it18151.htm