防止到 String 類的不恰當?shù)念愋娃D(zhuǎn)換

2019-11-18 12:10:58

字體：大中小

供稿：網(wǎng)友

　　作者：Fernando Ribeiro
　　
　　充分利用 java 語言多態(tài)性
　　
　　級別：中級
　　
　　在 Java 編程中，將對象轉(zhuǎn)換為字符串（或字符串化）可能引起問題，除非您記住在純粹的面向?qū)ο髴?yīng)用程序中很少使用字符串表示法。在本文中，系統(tǒng)分析員兼程序員 Fernando Ribeiro 以 Eric Allen 的錯誤模式概念為基礎(chǔ)建立了其觀點，并說明了錯誤的字符串化是如何成為錯誤模式的；他討論了對這種難以捉摸的缺陷的診斷并解釋了類型安全的好處。
　　字符串化是從對象到字符串的轉(zhuǎn)換，而對于本文，錯誤的字符串化是指對 String 類的不恰當?shù)念愋娃D(zhuǎn)換。例如，本文中的示例將向您展示產(chǎn)品代碼很少是字符串，但許多開發(fā)人員會將其類型轉(zhuǎn)換為 String 類，因而將危及面向?qū)ο缶幊讨械亩鄳B(tài)性的廣泛用途。
　　
　　盡管看起來只是樣式問題（因為錯誤字符串化“錯誤模式”的一個隱蔽屬性就是：它在任何時候（即使是測試時）都不引起任何錯誤），但避免對 String 類進行不恰當?shù)念愋娃D(zhuǎn)換可以使您充分利用 Java 語言內(nèi)在的多態(tài)性特性。在實踐方面，避免這種模式是防止它的最佳方法，而避免它的最佳方法是為您代碼中的大多數(shù)元素定義一個特定的類型。通過這樣做，您確保了每個類的類型適合于其任務(wù)，從而確保了系統(tǒng)的可靠性。這個解決方案會對您的系統(tǒng)性能增加一些開銷，但換來的是一個可靠得多的系統(tǒng)。
　　
　　在本文中，我們將在企業(yè)系統(tǒng)環(huán)境中討論這個模式，并且將研究一種檢測這種錯誤的方法：方法的錯誤重載。（我們不會在本文中過多地討論修改錯誤，因為，簡單地避免使用字符串表示是解決該問題最佳和最常見的方法。）
　　
　　聚焦 String 不恰當?shù)念愋娃D(zhuǎn)換
　　我喜歡和研究錯誤模式一樣來研究不恰當?shù)貙㈩愋娃D(zhuǎn)換為 String 類這一問題。因此，讓我們將這種問題稱為錯誤字符串化錯誤模式。（有關(guān)錯誤模式的更多信息，請參閱參考資料中 Eric Allen 的診斷 Java 代碼專欄文章。）
　　
　　幾個定義
　　對于不熟悉本文中使用的所有術(shù)語的讀者，這些定義應(yīng)該有助于您跟上進度：
　　UML（統(tǒng)一建模語言）：通過制定計劃或“藍圖”來簡化軟件設(shè)計過程，以此來明確說明、可視化、構(gòu)造和文檔化軟件系統(tǒng)構(gòu)件的語言。
　　
　　OCL（對象約束語言）：統(tǒng)一建模語言（UML）的表達語言；它具有純表達語言（不能更改模型中的任何東西）、建模語言（所有實現(xiàn)問題均超出范圍并無法表達）和形式語言（所有構(gòu)造都有形式定義的意義）的特征。
　　
　　類型安全的、類型安全：指定類型的 UML 模型元素（如字段或操作），其結(jié)構(gòu)和行為最貼切地符合元素規(guī)范。
　　
　　字符串化：將對象轉(zhuǎn)換成字符串。
　　
　　多態(tài)性：在面向?qū)ο缶幊讨校幊陶Z言根據(jù)對象的類型以不同方式處理它們的能力。
　　
　　方法重載：在面向?qū)ο髴?yīng)用程序中重新定義派生類的方法的能力，其中方法名稱保持相同，但參數(shù)的類型更改了。
　　
　　在我們繼續(xù)討論之前，請答應(yīng)我迅速討論一下類型安全的概念。當 UML 模型元素是類型安全的時，其結(jié)構(gòu)和行為貼切地與其規(guī)范相匹配，或者換句話說，它是明確地為其用途開發(fā)的。有助于您理解的示例是：搜索索引列表的操作的“鍵”參數(shù)不是一個字符串，而只是一個對象，類似于其它 Java 對象，可以通過調(diào)用 toString() : String 方法將它字符串化。差異在于字符串可以求子字符串、連接等；但鍵不能。它們是鍵，不是字符串。
　　
　　在類型安全的應(yīng)用程序中，color 字段的類型、getColor(): String 方法的返回類型和 setColor(color : String) : void 方法的 color 參數(shù)的類型都是 Color 而不是 String — 它返回車輛的顏色而不是其字符串表示。清單 1 提供了示例。
　　
　　在本文的代碼示例中，我們將使用一個假想的企業(yè)系統(tǒng)，該系統(tǒng)包括汽車工業(yè)產(chǎn)品的運輸和跟蹤功能。我們將為這個系統(tǒng)定義類，包括 Vehicle 類（當我們討論單個車輛細節(jié)時使用）和更普通的 PRodUCt 類（作為一般企業(yè)產(chǎn)品目錄的示例）。
　　
　　清單 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;
　　 }
　　
　　}
　　
　　這種錯誤模式出現(xiàn)在許多企業(yè)系統(tǒng)（包括產(chǎn)品目錄）中。研究下列代碼以獲得示例（這個示例也定義了 Product 類）：
　　
　　清單 2. 錯誤字符串化的產(chǎn)品
　　/**
　　* 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();
　　 }
　　
　　}
　　
　　
　　關(guān)于上述代碼中 Product 類設(shè)計的幾點注釋：
　　
　　第一個構(gòu)造函數(shù)是空的并且不獲取任何參數(shù)。
　　第二個構(gòu)造函數(shù)獲取一段代碼。
　　這些代碼組成（屬于）產(chǎn)品。
　　產(chǎn)品的字符串表示是空字符串。
　　產(chǎn)品按其代碼來比較是否相等。
　　產(chǎn)品的散列碼是其代碼的散列碼。
　　讓我們研究一下用于最后兩項的一些代碼示例。
　　
　　產(chǎn)品按其代碼來比較是否相等
　　以下是說明這一點的 OCL 約束：
　　
　　
　　context Product::equals(b : Object) : boolean
　　 pre: b.oclISKINdOf(Product);
　　 post: result = self.getCode().equals(b.oclAsType(Product).getCode());
　　
　　
　　產(chǎn)品及其代碼的散列碼相同
　　以下是說明這一點的 OCL 約束：
　　
　　context Product::hashCode() : int post:
　　 let code : String = self.getCode() in
　　 if code.oclIsUndefined() then
　　 result = 0;
　　 else
　　 result = code.hashCode();
　　 end if
　　
　　
　　以下是發(fā)生錯誤字符串化錯誤模式能夠削弱您產(chǎn)生良好代碼的能力的原因 — 產(chǎn)品代碼不是字符串，因為它所需要的結(jié)構(gòu)和行為可能超出 String 類所答應(yīng)的范圍。
　　
　　（本文中 OCL 約束是基于 OCL 2.0 建議的 — 例如，在 OCL 1.4 中不存在“oclIsNew”。有關(guān) OCL 的更多信息，請參閱參考資料。）
　　
　　產(chǎn)品代碼還可能需要專門化（如銷售或工程產(chǎn)品代碼）。并且某些產(chǎn)品可能被多次編碼 — 工程代碼可能被用于后勤系統(tǒng)；后勤代碼可能被用于銷售系統(tǒng)；工程、后勤和銷售代碼都可能被用于電子商務(wù)系統(tǒng)。產(chǎn)品代碼的用法需求有幾分象指揮開發(fā)人員的紅旗，把他們引向為每種產(chǎn)品代碼開發(fā)新的特定類型的方法。
　　
　　那么為什么會發(fā)生這種問題呢？而我們又應(yīng)該如何修正或避免它？
　　
　　問題和一些解決方案
　　問題之所以會發(fā)生，是因為大多數(shù)程序員沒有在面向?qū)ο髴?yīng)用程序中利用類型安全。（請記住，我們認為值得另外花一些力氣去定義一個特定于需求的新類型而不是依靠現(xiàn)有的類型，因為現(xiàn)有類型可能不夠匹配并可能引起問題。）下列車輛問題嘗到了類型安全應(yīng)用程序的甜頭，其中車輛（轎車和卡車）是由不同的船運輸?shù)摹Ｕ堁芯肯铝写a：
　　
　　/**
　　* Deliver a vehicle
　　* @param vehicle A vehicle
　　**/
　　public void deliver(String vehicle) {
　　 // is it a car or a truck?
　　}
　　
　　deliver(vehicle : String) : void 方法實現(xiàn)了字符串的傳遞（令人沮喪但事實如此）而不是車輛的傳遞，因為任何字符串都可以指定給 vehicle 參數(shù)。這實際上不是該問題的

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

下一篇：8條用于分布式計算的架構(gòu)技巧