Java

“對於物件導向的程式設計語言，多型性是第三種最基本的特徵（前兩種是資料抽象和繼承。”“多型”（Polymorphism）從另一個角度將介面從具體的實施細節中分離出來，亦即實現了“是什麼”與“怎樣做”兩個模組的分離。利用多型的概念，代碼的組織以及可讀性均能獲得改善。此外，還能建立“易於擴充”的程式。無論在項目的建立過程中，還是在需要加入新特性的時候，它們都可以方便地“

我們有必要對整個初始化過程有所認識，其中包括繼承，對這個過程中發生的事情有一個整體性的概念。請觀察下述代碼： //: Beetle.java// The full process of initialization.class Insect { int i = 9; int j; Insect() { prt("i = " + i + ", j = " + j); j = 39; } static int x1 =

如果說整個類都是final（在它的定義前冠以final關鍵字），就表明自己不希望從這個類繼承，或者不允許其他任何人採取這種操作。換言之，出於這樣或那樣的原因，我們的類肯定不需要進行任何改變；或者出於安全方面的理由，我們不希望進行子類化（子類處理）。除此以外，我們或許還考慮到執行效率的問題，並想確保涉及這個類各對象的所有行動都要儘可能地有效。如下所示： //: Jurassic.java// Making an entire class finalclass SmallBrain

許多程式設計語言都有自己的辦法告訴編譯器某個資料是“常數”。常數主要應用於下述兩個方面：(1) 編譯期常數，它永遠不會改變(2) 在運行期初始化的一個值，我們不希望它發生變化對於編譯期的常數，編譯器（程式）可將常數值“封裝”到需要的計算過程裡。也就是說，計算可在編譯期間提前執行，從而節省運行時的一些開銷。在Java中，這些形式的常數必須屬於基礎資料型別 (Elementary Data

之所以叫作這個名字，除了有一定的曆史原因外，也是由於在傳統意義上，類繼承圖的畫法是根位於最頂部，再逐漸向下擴充（當然，可根據自己的習慣用任何方法描繪這種圖）。因素，Wind.java的繼承圖就象下面這個樣子：由於造型的方向是從衍生類到基礎類，箭頭朝上，所以通常把它叫作“上溯造型”，即Upcasting。上溯造型肯定是安全的，因為我們是從一個更特殊的類型到一個更常規的類型。換言之，衍生類是基礎類的一個超集。它可以包含比基礎類更多的方法，但它至少包含了基礎類的方法。進行上溯造

只有C++程式員可能才會驚訝於名字的隱藏，因為它的工作原理與在C++裡是完全不同的。如果Java基礎類有一個方法名被“過載”使用多次，在衍生類裡對那個方法名的重新定義就不會隱藏任何基礎類的版本。所以無論方法在這一級還是在一個基礎類中定義，過載都會生效： //: Hide.java// Overloading a base-class method name// in a derived class does not hide the// base-class

Java不具備象C++的“破壞器”那樣的概念。在C++中，一旦破壞（清除）一個對象，就會自動調用破壞器方法。之所以將其省略，大概是由於在Java中只需簡單地忘記對象，不需強行破壞它們。垃圾收集器會在必要的時候自動回收記憶體。垃圾收集器大多數時候都能很好地工作，但在某些情況下，我們的類可能在自己的存在時期採取一些行動，而這些行動要求必須進行明確的清除工作。正如第4章已經指出的那樣，我們並不知道垃圾收集器什麼時候才會顯身，或者說不知它何時會調用。所以一旦希望為一個類清除什麼東

繼承與Java（以及其他OOP語言）非常緊密地結合在一起。我們早在第1章就為大家引入了繼承的概念，並在那章之後到本章之前的各章裡不時用到，因為一些特殊的場合要求必須使用繼承。除此以外，建立一個類時肯定會進行繼承，因為若非如此，會從Java的標準根類Object中繼承。用於合成的文法是非常簡單且直觀的。但為了進行繼承，必須採用一種全然不同的形式。需要繼承的時候，我們會說：“這個新類和那箇舊類差不多。”為了在代碼裡表面這一觀念，需要給出類名。但在類主體的起始花括弧之前，需要放

就以前的學習情況來看，事實上已進行了多次“合成”操作。為進行合成，我們只需在新類裡簡單地置入物件控點即可。舉個例子來說，假定需要在一個對象裡容納幾個String對象、兩種基礎資料型別 (Elementary Data Type)以及屬於另一個類的一個對象。對於非基本類型的對象來說，只需將控制代碼置於新類即可；而對於基礎資料型別 (Elementary Data

“Java令人信服的一項特性是代碼的重複使用或者再生。但最具革命意義的是，除代碼的複製和修改以外，我們還能做多得多的其他事情。”在象C那樣的程式化語言裡，代碼的重複使用早已可行，但效果不是特別顯著。與Java的其他地方一樣，這個方案解決的也是與類有關的問題。我們通過建立新類來重複使用代碼，但卻用不著重新建立，可以直接使用別人已建好並調試好的現成類。但這樣做必須保證不會干擾原有的代碼。在這一章裡，我們將介紹兩個達到這一目標的方法。第一個最簡單：在新類裡簡單地建立原有類的對象

(1) 用public、private、protected以及“友好的”資料成員及方法成員建立一個類。建立屬於這個類的一個對象，並觀察在試圖訪問所有類成員時會獲得哪種類型的編譯器錯誤提示。注意同一個目錄內的類屬於“預設”包的一部分。(2) 用protected資料建立一個類。在相同的檔案裡建立第二個類，用一個方法操縱第一個類裡的protected資料。(3)

對於任何關係，最重要的一點都是規定好所有方面都必須遵守的界限或規則。建立一個庫時，相當於建立了同那個庫的使用者（即“客戶程式員”）的一種關係——那些使用者屬於另外的程式員，可能用我們的庫自行構建一個應用程式，或者用我們的庫構建一個更大的庫。如果不制訂規則，客戶程式員就可以隨心所欲地操作一個類的所有成員，無論我們本來願不願意其中的一些成員被直接操作。所有東西都在別人面前都暴露無遺。本章講述了如何構建類，從而製作出理想的庫。首先，我們講述如何將一組類封

在Java中，亦可用訪問指示符判斷出一個庫內的哪些類可由那個庫的使用者使用。若想一個類能由客戶程式員調用，可在類主體的起始花括弧前面某處放置一個public關鍵字。它控制著客戶程式員是否能夠建立屬於這個類的一個對象。為控制一個類的訪問，指示符必須在關鍵字class之前出現。所以我們能夠使用：public class Widget {也就是說，假若我們的庫名是mylib，那麼所有客戶程式員都能訪問Widget——通過下述語句：import

介面中定義的欄位會自動具有static和final屬性。它們不能是“空白final”，但可初始化成非常數運算式。例如： //: RandVals.java// Initializing interface fields with // non-constant initializersimport java.util.*;public interface RandVals { int rint = (int)(Math.random() * 10);

由於置入一個介面的所有欄位都自動具有static和final屬性，所以介面是對常數值進行分組的一個好工具，它具有與C或C++的enum非常相似的效果。如下例所示： //: Months.java// Using interfaces to create groups of constantspackage c07;public interface Months { int JANUARY = 1, FEBRUARY = 2, MARCH = 3, APRIL = 4,

介面只是比抽象類別“更純”的一種形式。它的用途並不止那些。由於介面根本沒有具體的實施細節——也就是說，沒有與儲存空間與“介面”關聯在一起——所以沒有任何辦法可以防止多個介面合并到一起。這一點是至關重要的，因為我們經常都需要表達這樣一個意思：“x從屬於a，也從屬於b，也從屬於c”。在C++中，將多個類合并到一起的行動稱作“多重繼承”，而且操作較為不便，因為

“interface”（介面）關鍵字使抽象的概念更深入了一層。我們可將其想象為一個“純”抽象類別。它允許建立者規定一個類的基本形式：方法名、自變數列表以及傳回型別，但不規定方法主體。介面也包含了基礎資料型別 (Elementary Data

在我們所有樂器（Instrument）例子中，基礎類Instrument內的方法都肯定是“偽”方法。若去調用這些方法，就會出現錯誤。那是由於Instrument的意圖是為從它衍生出去的所有類都建立一個通用介面。之所以要建立這個通用介面，唯一的原因就是它能為不同的子類型作出不同的表示。它為我們建立了一種基本形式，使我們能定義在所有衍生類裡“通用”的一些東西。為闡述這個觀念，另一個方法是把Instrument稱為“抽象基礎類”（

現在讓我們用不同的眼光來看看本章的頭一個例子。在下面這個程式中，方法play()的介面會在被覆蓋的過程中發生變化。這意味著我們實際並沒有“覆蓋”方法，而是使其“過載”。編譯器允許我們對方法進行過載處理，使其不報告出錯。但這種行為可能並不是我們所希望的。下面是這個例子： //: WindError.java // Accidentally changing the interfaceclass NoteX { public static

現在，讓我們仍然返回樂器（Instrument）樣本。由於存在多型，所以可根據自己的需要向系統裡加入任意多的新類型，同時毋需更改true()方法。在一個設計良好的OOP程式中，我們的大多數或者所有方法都會遵從tune()的模型，而且只與基礎類介面通訊。我們說這樣的程式具有“擴充性”，因為可以從通用的基礎類繼承新的資料類型，從而新添一些功能。如果是為了適應新類的要求，那麼對基礎類介面進行操縱的方法根本不需要改變，對於樂器例子，假設我們在基礎類裡加入更多的方法，以及一系列新類