# 1.5 繼承：重新使用接口 就其本身來說，對象的概念可為我們帶來極大的便利。它在概念上允許我們將各式各樣數據和功能封裝到一起。這樣便可恰當表達“問題空間”的概念，不用刻意遵照基礎機器的表達方式。在程序設計語言中，這些概念則反映為具體的數據類型（使用`class`關鍵字）。 我們費盡心思做出一種數據類型后，假如不得不又新建一種類型，令其實現大致相同的功能，那會是一件非常令人灰心的事情。但若能利用現成的數據類型，對其進行“克隆”，再根據情況進行添加和修改，情況就顯得理想多了。“繼承”正是針對這個目標而設計的。但繼承并不完全等價于克隆。在繼承過程中，若原始類（正式名稱叫作基類、超類或父類）發生了變化，修改過的“克隆”類（正式名稱叫作繼承類或者子類）也會反映出這種變化。在Java語言中，繼承是通過`extends`關鍵字實現的 使用繼承時，相當于創建了一個新類。這個新類不僅包含了現有類型的所有成員（盡管`private`成員被隱藏起來，且不能訪問），但更重要的是，它復制了基類的接口。也就是說，可向基類的對象發送的所有消息亦可原樣發給派生類的對象。根據可以發送的消息，我們能知道類的類型。這意味著派生類具有與基類相同的類型！為真正理解面向對象程序設計的含義，首先必須認識到這種類型的等價關系。 由于基類和派生類具有相同的接口，所以那個接口必須進行特殊的設計。也就是說，對象接收到一條特定的消息后，必須有一個“方法”能夠執行。若只是簡單地繼承一個類，并不做其他任何事情，來自基類接口的方法就會直接照搬到派生類。這意味著派生類的對象不僅有相同的類型，也有同樣的行為，這一后果通常是我們不愿見到的。 有兩種做法可將新得的派生類與原來的基類區分開。第一種做法十分簡單：為派生類添加新函數（功能）。這些新函數并非基類接口的一部分。進行這種處理時，一般都是意識到基類不能滿足我們的要求，所以需要添加更多的函數。這是一種最簡單、最基本的繼承用法，大多數時候都可完美地解決我們的問題。然而，事先還是要仔細調查自己的基類是否真的需要這些額外的函數。 ## 1.5.1 改善基類 盡管`extends`關鍵字暗示著我們要為接口“擴展”新功能，但實情并非肯定如此。為區分我們的新類，第二個辦法是改變基類一個現有函數的行為。我們將其稱作“改善”那個函數。 為改善一個函數，只需為派生類的函數建立一個新定義即可。我們的目標是：“盡管使用的函數接口未變，但它的新版本具有不同的表現”。 ## 1.5.2 等價與類似關系 針對繼承可能會產生這樣的一個爭論：繼承只能改善原基類的函數嗎？若答案是肯定的，則派生類型就是與基類完全相同的類型，因為都擁有完全相同的接口。這樣造成的結果就是：我們完全能夠將派生類的一個對象換成基類的一個對象！可將其想象成一種“純替換”。在某種意義上，這是進行繼承的一種理想方式。此時，我們通常認為基類和派生類之間存在一種“等價”關系——因為我們可以理直氣壯地說：“圓就是一種幾何形狀”。為了對繼承進行測試，一個辦法就是看看自己是否能把它們套入這種“等價”關系中，看看是否有意義。 但在許多時候，我們必須為派生類型加入新的接口元素。所以不僅擴展了接口，也創建了一種新類型。這種新類型仍可替換成基類型，但這種替換并不是完美的，因為不可在基類里訪問新函數。我們將其稱作“類似”關系；新類型擁有舊類型的接口，但也包含了其他函數，所以不能說它們是完全等價的。舉個例子來說，讓我們考慮一下制冷機的情況。假定我們的房間連好了用于制冷的各種控制器；也就是說，我們已擁有必要的“接口”來控制制冷。現在假設機器出了故障，我們把它換成一臺新型的冷、熱兩用空調，冬天和夏天均可使用。冷、熱空調“類似”制冷機，但能做更多的事情。由于我們的房間只安裝了控制制冷的設備，所以它們只限于同新機器的制冷部分打交道。新機器的接口已得到了擴展，但現有的系統并不知道除原始接口以外的任何東西。 認識了等價與類似的區別后，再進行替換時就會有把握得多。盡管大多數時候“純替換”已經足夠，但您會發現在某些情況下，仍然有明顯的理由需要在派生類的基礎上增添新功能。通過前面對這兩種情況的討論，相信大家已心中有數該如何做。