防止到 String 类的不恰当的类型转换

2019-11-18 12:10:58

字体：大中小

来源：转载

供稿：网友

　　作者：Fernando Ribeiro
　　
　　充分利用 java 语言多态性
　　
　　级别：中级
　　
　　在 Java 编程中，将对象转换为字符串（或字符串化）可能引起问题，除非您记住在纯粹的面向对象应用程序中很少使用字符串表示法。在本文中，系统分析员兼程序员 Fernando Ribeiro 以 Eric Allen 的错误模式概念为基础建立了其观点，并说明了错误的字符串化是如何成为错误模式的；他讨论了对这种难以捉摸的缺陷的诊断并解释了类型安全的好处。
　　字符串化是从对象到字符串的转换，而对于本文，错误的字符串化是指对 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 参数。这实际上不是该问题的

上一篇：Java高级日期概念二

下一篇：8条用于分布式计算的架构技巧