輕松掌握 Java 泛型 (第 3 部分)

2019-11-18 13:15:10

字體：大中小

供稿：網(wǎng)友

　　有效的構(gòu)造函數(shù)調(diào)用
　　首先，為了對類型參數(shù)構(gòu)造合法的 new 表達式（如 new T()），必須確保我們調(diào)用的構(gòu)造函數(shù)對于 T 的每個實例化都有效。但由于我們只知道 T 是其已聲明界限的子類型，所以我們不知道 T 的某一實例化將有什么構(gòu)造函數(shù)。要解決這一問題，可以用下述三種方法之一：
　　
　　要求類型參數(shù)的所有實例化都包括不帶參數(shù)的（zeroary）構(gòu)造函數(shù)。
　　只要泛型類的運行時實例化沒有包括所需的構(gòu)造函數(shù)，就拋出異常。
　　修改語言的語法以包括更詳盡的類型參數(shù)界限。
　　
　　第 1 種方法：需要不帶參數(shù)的構(gòu)造函數(shù)
　　只要求類型參數(shù)的所有實例化都包括不帶參數(shù)的構(gòu)造函數(shù)。該解決方案的優(yōu)點是非常簡單。使用這種方法也有先例。
　　
　　處理類似問題的現(xiàn)有 java 技術(shù)（象 JavaBean 技術(shù)）就是通過要求一個不帶參數(shù)的構(gòu)造函數(shù)來解決問題的。然而，該方法的一個主要缺點是：對于許多類，沒有合理的不帶參數(shù)的構(gòu)造函數(shù)。
　　
　　例如，表示非空容器的任何類在構(gòu)造函數(shù)中必然使用表示其元素的參數(shù)。包括不帶參數(shù)的構(gòu)造函數(shù)將迫使我們先創(chuàng)建實例，然后再進行本來可以在構(gòu)造函數(shù)調(diào)用中完成的初始化。但該實踐會導致問題的產(chǎn)生（您可能想要閱讀 2002 年 4 月發(fā)表的本專欄文章“The Run-on Initializer bug pattern”，以獲取具體信息；請參閱參考資料。）
　　
　　第 2 種方法：當缺少所需構(gòu)造函數(shù)時，拋出異常
　　處理該問題的另一種方法是：只要泛型類的運行時實例化沒有包括所需構(gòu)造函數(shù)，就拋出異常。請注重：必須在運行時拋出異常。因為 Java 語言的遞增式編譯模型，所以我們無法靜態(tài)地確定所有將在運行時發(fā)生的泛型類的實例化。例如，假設我們有如下一組泛型類：
　　
　　清單 1.“裸”類型參數(shù)的 New 操作
　　
　　class C< T> {
　　　T makeT() {
　　　　return new T();
　　　}
　　}
　　
　　class D< S> {
　　　C< S> makeC() {
　　　　return new C< S>();
　　　}
　　}
　　
　　現(xiàn)在，在類 D< S> 中，構(gòu)造了類 C< S> 的實例。然后，在類 C 的主體中，將調(diào)用 S 的不帶參數(shù)的構(gòu)造函數(shù)。這種不帶參數(shù)的構(gòu)造函數(shù)存在嗎？答案當然取決于 S 的實例化！
　　
　　比方說，假如 S 被實例化為 String，那么答案是“存在”。假如它被實例化為 Integer，那么答案是“不存在”。但是，當編譯類 D 和 C 時，我們不知道其它類會構(gòu)造什么樣的 D< S> 實例化。即使我們有可用于分析的整個程序（我們幾乎從來沒有這樣的 Java 程序），我們還是必須進行代價相當高的流分析來確定潛在的構(gòu)造函數(shù)問題可能會出現(xiàn)在哪里。
　　
　　此外，這一技術(shù)所產(chǎn)生的錯誤種類對于程序員來說很難診斷和修復。例如，假設程序員只熟悉類 D 的頭。他知道 D 的類型參數(shù)的界限是缺省界限（Object）。假如得到那樣的信息，他沒有理由相信滿足聲明類型界限（如 D< Integer>）的 D 的實例化將會導致錯誤。事實上，它在相當長的時間里都不會引起錯誤，直到最后有人調(diào)用方法 makeC 以及（最終）對 C 的實例化調(diào)用方法 makeT。然后，我們將得到一個報告的錯誤，但這將在實際問題發(fā)生很久以后 — 類 D 的糟糕實例化。
　　
　　還有，對所報告錯誤的堆棧跟蹤甚至可能不包括任何對這個糟糕的 D 實例的方法調(diào)用！現(xiàn)在，讓我們假設程序員無權(quán)訪問類 C 的源代碼。他對問題是什么或如何修正代碼將毫無頭緒，除非他設法聯(lián)系類 C 的維護者并獲得線索。
　　
　　第 3 種方法：修改語法以獲得更詳盡的界限
　　另一種可能性是修改語言語法以包括更詳盡的類型參數(shù)界限。這些界限可以指定一組可用的構(gòu)造函數(shù)，它們必須出現(xiàn)在參數(shù)的每一個實例化中。因而，在泛型類定義內(nèi)部，唯一可調(diào)用的構(gòu)造函數(shù)是那些在界限中聲明的構(gòu)造函數(shù)。
　　
　　同樣，實例化泛型類的客戶機類必須使用滿足對構(gòu)造函數(shù)存在所聲明的約束的類來這樣做。參數(shù)聲明將充當類與其客戶機之間的契約，這樣我們可以靜態(tài)地檢查這兩者是否遵守契約。
　　
　　與另外兩種方法相比，該方法有許多優(yōu)點，它答應我們保持第二種方法的可表達性以及與第一種方法中相同的靜態(tài)檢查程度。但它也有需要克服的問題。
　　
　　首先，類型參數(shù)聲明很輕易變得冗長。我們或許需要某種形式的語法上的甜頭，使這些擴充的參數(shù)聲明還過得去。另外，假如在 Tiger 以后的版本中添加擴充的參數(shù)聲明，那么我們必須確保這些擴充的聲明將與現(xiàn)有的已編譯泛型類兼容。
　　
　　假如將對泛型類型的與類型相關(guān)的操作的支持添加到 Java 編程中，那么它采用何種形式還不清楚。但是，從哪種方法將使 Java 代碼盡可能地保持健壯（以及使在它遭到破壞時盡可能輕易地修正）的觀點看，第三個選項無疑是最適合的。
　　
　　然而，new 表達式有另一個更嚴重的問題。
　　
　　多態(tài)遞歸
　　更嚴重的問題是類定義中可能存在多態(tài)遞歸。當泛型類在其自己的主體中實例化其本身時，發(fā)生多態(tài)遞歸。例如，考慮下面的錯誤示例：
　　
　　清單 2. 自引用的泛型類
　　
　　class C< T> {
　　　public Object nest(int n) {
　　　　if (n == 0) return this;
　　　　else return new C< C< T>>().nest(n - 1);
　　　}
　　}
　　
　　假設客戶機類創(chuàng)建新的 C< Object> 實例，并調(diào)用（比方說）nest(1000)。然后，在執(zhí)行方法 nest() 的過程中，將構(gòu)造新的實例化 C< C< Object>>，并且對它調(diào)用 nest(999)。然后，將構(gòu)造實例化 C< C< C< Object>>>，以此類推，直到構(gòu)造 1000 個獨立的類 C 的實例化。當然，我隨便選擇數(shù)字 1000；通常，我們無法知道在運行時哪些整數(shù)將被傳遞到方法 nest。事實上，可以將它們作為用戶輸入傳入。
　　
　　為什么這成為問題呢？因為假如我們通過為每個實例化構(gòu)造獨立類來支持泛型類型的與類型相關(guān)的操作，那么，在程序運行以前，我們無法知道我們需要構(gòu)造哪些類。但是，假如類裝入器為它所裝入的每個類查找現(xiàn)有類文件，那么它會如何工作呢？
　　
　　同樣，這里有幾種可能的解決辦法：
　　
　　對程序可以產(chǎn)生的泛型類的實例化數(shù)目設置上限。
　　靜態(tài)禁止多態(tài)遞歸。
　　在程序運行時隨需構(gòu)造新的實例化類。
　　
　　第 1 種：對實例化數(shù)設置上限
　　我們對程序可以產(chǎn)生的泛型類的實例化數(shù)目設置上限。然后，在編譯期間，我們可以對一組合法的實例化確定有限界限，并且僅為該界限中的所有實例化生成類文件。
　　
　　該方法類似于在 C++ 標準模板庫中完成的事情（這使我們有理由擔心它不是一個好方法）。該方法的問題是，和為錯誤的構(gòu)造函數(shù)調(diào)用報告錯誤一樣，程序員將無法預知其程序的某一次運行將崩潰。例如，假設實例化數(shù)的界限為 42，并且使用用戶提供的參數(shù)調(diào)用先前提到的 nest() 方法。那么，只要用戶輸入小于 42 的數(shù)，一切都正常。當用戶輸入 43 時，這一計劃不周的設計就會失敗。現(xiàn)在，設想一下可憐的代碼維護者，他所面對的任務是重新組合代碼并試圖弄清楚幻數(shù) 42 有什么非凡之處。
　　
　　第 2 種：靜態(tài)禁止多態(tài)遞歸
　　為什么我們不向編譯器發(fā)出類似“靜態(tài)禁止多態(tài)遞歸”這樣的命令呢？（唉！要是那么簡單就好了。）當然，包括我在內(nèi)的許多程序員都會反對這種策略，它抑制了許多重要設計模式的使用。
　　
　　例如，在泛型類 List< T> 中，您真的想要防止 List< List< T>> 的構(gòu)造嗎？從方法返回這種列表對于構(gòu)建許多很常用的數(shù)據(jù)結(jié)構(gòu)很有用。事實證實我們無法防止多態(tài)遞歸，即使我們想要那樣，也是如此。就象靜態(tài)檢測糟糕的泛型構(gòu)造函數(shù)調(diào)用一樣，禁止多態(tài)遞歸會與遞增式類編譯發(fā)生沖突。我們先前的簡單示例（其中，多態(tài)遞歸作為一個簡單直接的自引用發(fā)生）會使這一事實變得模糊。但是，自引用對于在不同時間編譯的大多數(shù)類經(jīng)常采用任意的間接級別。再提一次，那是因為一個泛型類可以用其自己的類型參數(shù)來實例化另一個泛型類。
　　
　　下面的示例涉及兩個類之間的多態(tài)遞歸：
　　
　　清單 3. 相互遞歸的多態(tài)遞歸
　　
　　class C< T> {
　　　public Object potentialNest(int n) {
　　　　if (n == 0) return this;
　　　　else return new D< T>().nest(n - 1);
　　　}
　　}
　　
　　class D< S> {
　　　public Object nest(int n) {
　　　　return new C< C< S>>().nest(n);
　　　}
　　}
　　
　　在類 C 或 D 中顯然沒有多態(tài)遞歸，但象 new D< C< Object>>().nest(1000) 之類的表達式將引起類 C 的 1000 次實例化。
　　
　　或許，我們可以將新屬性添加到類文件中，以表明類中所有不同泛型類型實例化，然后在編譯其它類時分析這些實例化，以進行遞歸。但是，我們還是必須向程序員提供希奇的和不直觀的錯誤消息。
　　
　　在上面的代碼中，我們在哪里報告錯誤呢？在類 D 的編譯過程中還是在包含不相干表達式 new D< C< Object>>().nest(1000) 的客戶機類的編譯過程中呢？無論是哪一種，除非程序員有權(quán)訪問類 C 的源代碼，否則他無法預知何時會發(fā)生編譯錯誤。
　　
　　第 3 種：實時構(gòu)造新的實例化類
　　另一種方法是在程序運行時按需構(gòu)造新的實例化類。起先，這種方法似乎與 Java 運行時完全不兼容。但實際上，實現(xiàn)該策略所需的全部就是使用一個修改的類裝入器，它根據(jù)“模板（template）”類文件構(gòu)造新的實例化類。
　　
　　JVM 規(guī)范已經(jīng)答應程序員使用修改的類裝入器；事實上，許多流行的 Java 應用程序（如 Ant、JUnit 和 DrJava）都使用它們。該方法的缺點是：修改的類裝入器必須與其應用程序一起分布，以在較舊的 JVM 上運行。因為類裝入器往往比較小，所以這個開銷不會大。

上一篇：輕松掌握 Java 泛型 (第 4 部分)

下一篇：輕松掌握 Java 泛型 (第 2 部分)