# 7.8 通過繼承進行設計 學習了多態性的知識后，由于多態性是如此“聰明”的一種工具，所以看起來似乎所有東西都應該繼承。但假如過度使用繼承技術，也會使自己的設計變得不必要地復雜起來。事實上，當我們以一個現成類為基礎建立一個新類時，如首先選擇繼承，會使情況變得異常復雜。 一個更好的思路是首先選擇“組合”——如果不能十分確定自己應使用哪一個。組合不會強迫我們的程序設計進入繼承的分級結構中。同時，組合顯得更加靈活，因為可以動態選擇一種類型（以及行為），而繼承要求在編譯期間準確地知道一種類型。下面這個例子對此進行了闡釋： ``` //: Transmogrify.java // Dynamically changing the behavior of // an object via composition. interface Actor { void act(); } class HappyActor implements Actor { public void act() { System.out.println("HappyActor"); } } class SadActor implements Actor { public void act() { System.out.println("SadActor"); } } class Stage { Actor a = new HappyActor(); void change() { a = new SadActor(); } void go() { a.act(); } } public class Transmogrify { public static void main(String[] args) { Stage s = new Stage(); s.go(); // Prints "HappyActor" s.change(); s.go(); // Prints "SadActor" } } ///:~ ``` 在這里，一個`Stage`對象包含了指向一個`Actor`的引用，后者被初始化成一個`HappyActor`對象。這意味著`go()`會產生特定的行為。但由于引用在運行期間可以重新與一個不同的對象綁定或結合起來，所以`SadActor`對象的引用可在a中得到替換，然后由`go()`產生的行為發生改變。這樣一來，我們在運行期間就獲得了很大的靈活性。與此相反，我們不能在運行期間換用不同的形式來進行繼承；它要求在編譯期間完全決定下來。 一條常規的設計準則是：用繼承表達行為間的差異，并用成員變量表達狀態的變化。在上述例子中，兩者都得到了應用：繼承了兩個不同的類，用于表達`act()`方法的差異；而`Stage`通過組合技術允許它自己的狀態發生變化。在這種情況下，那種狀態的改變同時也產生了行為的變化。 ## 7.8.1 純繼承與擴展 學習繼承時，為了創建繼承分級結構，看來最明顯的方法是采取一種“純粹”的手段。也就是說，只有在基類或“接口”中已建立的方法才可在派生類中被覆蓋，如下面這張圖所示：  可將其描述成一種純粹的“屬于”關系，因為一個類的接口已規定了它到底“是什么”或者“屬于什么”。通過繼承，可保證所有派生類都只擁有基類的接口。如果按上述示意圖操作，派生出來的類除了基類的接口之外，也不會再擁有其他什么。 可將其想象成一種“純替換”，因為派生類對象可為基類完美地替換掉。使用它們的時候，我們根本沒必要知道與子類有關的任何額外信息。如下所示：  也就是說，基類可接收我們發給派生類的任何消息，因為兩者擁有完全一致的接口。我們要做的全部事情就是從派生向上轉換，而且永遠不需要回過頭來檢查對象的準確類型是什么。所有細節都已通過多態性獲得了完美的控制。 若按這種思路考慮問題，那么一個純粹的“屬于”關系似乎是唯一明智的設計方法，其他任何設計方法都會導致混亂不清的思路，而且在定義上存在很大的困難。但這種想法又屬于另一個極端。經過細致的研究，我們發現擴展接口對于一些特定問題來說是特別有效的方案。可將其稱為“類似于”關系，因為擴展后的派生類“類似于”基類——它們有相同的基礎接口——但它增加了一些特性，要求用額外的方法加以實現。如下所示：  盡管這是一種有用和明智的做法（由具體的環境決定），但它也有一個缺點：派生類中對接口擴展的那一部分不可在基類中使用。所以一旦向上轉換，就不可再調用新方法：  若在此時不進行向上轉換，則不會出現此類問題。但在許多情況下，都需要重新核實對象的準確類型，使自己能訪問那個類型的擴展方法。在后面的小節里，我們具體講述了這是如何實現的。 ## 7.8.2 向下轉換與運行期類型識別 由于我們在向上轉換（在繼承結構中向上移動）期間丟失了具體的類型信息，所以為了獲取具體的類型信息——亦即在分級結構中向下移動——我們必須使用 “向下轉換”技術。然而，我們知道一個向上轉換肯定是安全的；基類不可能再擁有一個比派生類更大的接口。因此，我們通過基類接口發送的每一條消息都肯定能夠接收到。但在進行向下轉換的時候，我們（舉個例子來說）并不真的知道一個幾何形狀實際是一個圓，它完全可能是一個三角形、方形或者其他形狀。  為解決這個問題，必須有一種辦法能夠保證向下轉換正確進行。只有這樣，我們才不會冒然轉換成一種錯誤的類型，然后發出一條對象不可能收到的消息。這樣做是非常不安全的。 在某些語言中（如C++），為了進行保證“類型安全”的向下轉換，必須采取特殊的操作。但在Java中，所有轉換都會自動得到檢查和核實！所以即使我們只是進行一次普通的括弧轉換，進入運行期以后，仍然會毫無留情地對這個轉換進行檢查，保證它的確是我們希望的那種類型。如果不是，就會得到一個`ClassCastException`（類轉換異常）。在運行期間對類型進行檢查的行為叫作“運行期類型識別”（RTTI）。下面這個例子向大家演示了RTTI的行為： ``` //: RTTI.java // Downcasting & Run-Time Type // Identification (RTTI) import java.util.*; class Useful { public void f() {} public void g() {} } class MoreUseful extends Useful { public void f() {} public void g() {} public void u() {} public void v() {} public void w() {} } public class RTTI { public static void main(String[] args) { Useful[] x = { new Useful(), new MoreUseful() }; x[0].f(); x[1].g(); // Compile-time: method not found in Useful: //! x[1].u(); ((MoreUseful)x[1]).u(); // Downcast/RTTI ((MoreUseful)x[0]).u(); // Exception thrown } } ///:~ ``` 和在示意圖中一樣，`MoreUseful`（更有用的）對`Useful`（有用的）的接口進行了擴展。但由于它是繼承來的，所以也能向上轉換到一個`Useful`。我們可看到這會在對數組`x`（位于`main()`中）進行初始化的時候發生。由于數組中的兩個對象都屬于`Useful`類，所以可將`f()`和`g()`方法同時發給它們兩個。而且假如試圖調用`u()`（它只存在于`MoreUseful`），就會收到一條編譯期出錯提示。 若想訪問一個`MoreUseful`對象的擴展接口，可試著進行向下轉換。如果它是正確的類型，這一行動就會成功。否則，就會得到一個`ClassCastException`。我們不必為這個異常編寫任何特殊的代碼，因為它指出的是一個可能在程序中任何地方發生的一個編程錯誤。 RTTI的意義遠不僅僅反映在轉換處理上。例如，在試圖向下轉換之前，可通過一種方法了解自己處理的是什么類型。整個第11章都在講述Java運行期類型識別的方方面面。