# 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運行期類型識別的方方面面。
- Java 編程思想
- 寫在前面的話
- 引言
- 第1章 對象入門
- 1.1 抽象的進步
- 1.2 對象的接口
- 1.3 實現方案的隱藏
- 1.4 方案的重復使用
- 1.5 繼承:重新使用接口
- 1.6 多態對象的互換使用
- 1.7 對象的創建和存在時間
- 1.8 異常控制:解決錯誤
- 1.9 多線程
- 1.10 永久性
- 1.11 Java和因特網
- 1.12 分析和設計
- 1.13 Java還是C++
- 第2章 一切都是對象
- 2.1 用引用操縱對象
- 2.2 所有對象都必須創建
- 2.3 絕對不要清除對象
- 2.4 新建數據類型:類
- 2.5 方法、參數和返回值
- 2.6 構建Java程序
- 2.7 我們的第一個Java程序
- 2.8 注釋和嵌入文檔
- 2.9 編碼樣式
- 2.10 總結
- 2.11 練習
- 第3章 控制程序流程
- 3.1 使用Java運算符
- 3.2 執行控制
- 3.3 總結
- 3.4 練習
- 第4章 初始化和清除
- 4.1 用構造器自動初始化
- 4.2 方法重載
- 4.3 清除:收尾和垃圾收集
- 4.4 成員初始化
- 4.5 數組初始化
- 4.6 總結
- 4.7 練習
- 第5章 隱藏實現過程
- 5.1 包:庫單元
- 5.2 Java訪問指示符
- 5.3 接口與實現
- 5.4 類訪問
- 5.5 總結
- 5.6 練習
- 第6章 類復用
- 6.1 組合的語法
- 6.2 繼承的語法
- 6.3 組合與繼承的結合
- 6.4 到底選擇組合還是繼承
- 6.5 protected
- 6.6 累積開發
- 6.7 向上轉換
- 6.8 final關鍵字
- 6.9 初始化和類裝載
- 6.10 總結
- 6.11 練習
- 第7章 多態性
- 7.1 向上轉換
- 7.2 深入理解
- 7.3 覆蓋與重載
- 7.4 抽象類和方法
- 7.5 接口
- 7.6 內部類
- 7.7 構造器和多態性
- 7.8 通過繼承進行設計
- 7.9 總結
- 7.10 練習
- 第8章 對象的容納
- 8.1 數組
- 8.2 集合
- 8.3 枚舉器(迭代器)
- 8.4 集合的類型
- 8.5 排序
- 8.6 通用集合庫
- 8.7 新集合
- 8.8 總結
- 8.9 練習
- 第9章 異常差錯控制
- 9.1 基本異常
- 9.2 異常的捕獲
- 9.3 標準Java異常
- 9.4 創建自己的異常
- 9.5 異常的限制
- 9.6 用finally清除
- 9.7 構造器
- 9.8 異常匹配
- 9.9 總結
- 9.10 練習
- 第10章 Java IO系統
- 10.1 輸入和輸出
- 10.2 增添屬性和有用的接口
- 10.3 本身的缺陷:RandomAccessFile
- 10.4 File類
- 10.5 IO流的典型應用
- 10.6 StreamTokenizer
- 10.7 Java 1.1的IO流
- 10.8 壓縮
- 10.9 對象序列化
- 10.10 總結
- 10.11 練習
- 第11章 運行期類型識別
- 11.1 對RTTI的需要
- 11.2 RTTI語法
- 11.3 反射:運行期類信息
- 11.4 總結
- 11.5 練習
- 第12章 傳遞和返回對象
- 12.1 傳遞引用
- 12.2 制作本地副本
- 12.3 克隆的控制
- 12.4 只讀類
- 12.5 總結
- 12.6 練習
- 第13章 創建窗口和程序片
- 13.1 為何要用AWT?
- 13.2 基本程序片
- 13.3 制作按鈕
- 13.4 捕獲事件
- 13.5 文本字段
- 13.6 文本區域
- 13.7 標簽
- 13.8 復選框
- 13.9 單選鈕
- 13.10 下拉列表
- 13.11 列表框
- 13.12 布局的控制
- 13.13 action的替代品
- 13.14 程序片的局限
- 13.15 視窗化應用
- 13.16 新型AWT
- 13.17 Java 1.1用戶接口API
- 13.18 可視編程和Beans
- 13.19 Swing入門
- 13.20 總結
- 13.21 練習
- 第14章 多線程
- 14.1 反應靈敏的用戶界面
- 14.2 共享有限的資源
- 14.3 堵塞
- 14.4 優先級
- 14.5 回顧runnable
- 14.6 總結
- 14.7 練習
- 第15章 網絡編程
- 15.1 機器的標識
- 15.2 套接字
- 15.3 服務多個客戶
- 15.4 數據報
- 15.5 一個Web應用
- 15.6 Java與CGI的溝通
- 15.7 用JDBC連接數據庫
- 15.8 遠程方法
- 15.9 總結
- 15.10 練習
- 第16章 設計模式
- 16.1 模式的概念
- 16.2 觀察器模式
- 16.3 模擬垃圾回收站
- 16.4 改進設計
- 16.5 抽象的應用
- 16.6 多重分發
- 16.7 訪問器模式
- 16.8 RTTI真的有害嗎
- 16.9 總結
- 16.10 練習
- 第17章 項目
- 17.1 文字處理
- 17.2 方法查找工具
- 17.3 復雜性理論
- 17.4 總結
- 17.5 練習
- 附錄A 使用非JAVA代碼
- 附錄B 對比C++和Java
- 附錄C Java編程規則
- 附錄D 性能
- 附錄E 關于垃圾收集的一些話
- 附錄F 推薦讀物