防止到 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條用于分布式計算的架構技巧