## 繼承 “對象”的概念給編程帶來便利。它在概念上允許我們將各式各樣的數據和功能封裝到一起，這樣便可恰當表達“問題空間”的概念，而不用受制于必須使用底層機器語言。 通過使用 `class` 關鍵字，這些概念形成了編程語言中的基本單元。遺憾的是，這么做還是有很多麻煩：在創建了一個類之后，即使另一個新類與其具有相似的功能，你還是得重新創建一個新類。但我們若能利用現成的數據類型，對其進行“克隆”，再根據情況進行添加和修改，情況就顯得理想多了。“繼承”正是針對這個目標而設計的。但繼承并不完全等價于克隆。在繼承過程中，若原始類（正式名稱叫作基類、超類或父類）發生了變化，修改過的“克隆”類（正式名稱叫作繼承類或者子類）也會反映出這種變化。  這個圖中的箭頭從派生類指向基類。正如你將看到的，通常有多個派生類。類型不僅僅描述一組對象的約束，它還涉及其他類型。兩種類型可以具有共同的特征和行為，但是一種類型可能包含比另一種類型更多的特征，并且還可以處理更多的消息（或者以不同的方式處理它們）。繼承通過基類和派生類的概念來表達這種相似性。基類包含派生自它的類型之間共享的所有特征和行為。創建基類以表示思想的核心。從基類中派生出其他類型來表示實現該核心的不同方式。  例如，垃圾回收機對垃圾進行分類。基類是“垃圾”。每塊垃圾都有重量、價值等特性，它們可以被切碎、熔化或分解。在此基礎上，可以通過添加額外的特性（瓶子有顏色，鋼罐有磁性）或行為（鋁罐可以被壓碎）派生出更具體的垃圾類型。此外，一些行為可以不同（紙張的價值取決于它的類型和狀態）。使用繼承，你將構建一個類型層次結構，來表示你試圖解決的某種類型的問題。第二個例子是常見的“形狀”例子，可能用于計算機輔助設計系統或游戲模擬。基類是“形狀”，每個形狀都有大小、顏色、位置等等。每個形狀可以繪制、擦除、移動、著色等。由此，可以派生出（繼承出）具體類型的形狀——圓形、正方形、三角形等等——每個形狀可以具有附加的特征和行為。  例如，某些形狀可以翻轉。有些行為可能不同，比如計算形狀的面積。類型層次結構體現了形狀之間的相似性和差異性。以相同的術語將解決方案轉換成問題是有用的，因為你不需要在問題描述和解決方案描述之間建立許多中間模型。通過使用對象，類型層次結構成為了主要模型，因此你可以直接從真實世界中對系統的描述過渡到用代碼對系統進行描述。事實上，有時候，那些善于尋找復雜解決方案的人會被面向對象設計的簡單性難倒。從現有類型繼承創建新類型。這種新類型不僅包含現有類型的所有成員（盡管私有成員被隱藏起來并且不可訪問），而且更重要的是它復制了基類的接口。也就是說，基類對象接收的所有消息也能被派生類對象接收。根據類接收的消息，我們知道類的類型，因此派生類與基類是相同的類型。 在前面的例子中，“圓是形狀”。這種通過繼承的類型等價性是理解面向對象編程含義的基本門檻之一。因為基類和派生類都具有相同的基本接口，所以伴隨此接口的必定有某些具體實現。也就是說，當對象接收到特定消息時，必須有可執行代碼。如果繼承一個類而不做其他任何事，則來自基類接口的方法直接進入派生類。這意味著派生類和基類不僅具有相同的類型，而且具有相同的行為，這么做沒什么特別意義。 有兩種方法可以區分新的派生類與原始的基類。第一種方法很簡單：在派生類中添加新方法。這些新方法不是基類接口的一部分。這意味著基類不能滿足你的所有需求，所以你添加了更多的方法。繼承的這種簡單而原始的用途有時是解決問題的完美解決方案。然而，還是要仔細考慮是否在基類中也要有這些額外的方法。這種設計的發現與迭代過程在面向對象程序設計中會經常發生。 盡管繼承有時意味著你要在接口中添加新方法（尤其是在以 **extends** 關鍵字表示繼承的 Java 中），但并非總需如此。第二種也是更重要地區分派生類和基類的方法是改變現有基類方法的行為，這被稱為覆蓋 (overriding)。要想覆蓋一個方法，只需要在派生類中重新定義這個方法即可。 ### "是一個"與"像是一個"的關系 對于繼承可能會引發爭論：繼承應該只覆蓋基類的方法(不應該添加基類中沒有的方法)嗎？如果這樣的話，基類和派生類就是相同的類型了，因為它們具有相同的接口。這會造成，你可以用一個派生類對象完全替代基類對象，這叫作"純粹替代"，也經常被稱作"替代原則"。在某種意義上，這是一種處理繼承的理想方式。我們經常把這種基類和派生類的關系稱為是一個（is-a）關系，因為可以說"圓是一個形狀"。判斷是否繼承，就看在你的類之間有無這種 is-a 關系。 有時你在派生類添加了新的接口元素，從而擴展接口。雖然新類型仍然可以替代基類，但是這種替代不完美，原因在于基類無法訪問新添加的方法。這種關系稱為像是一個(is-like-a)關系。新類型不但擁有舊類型的接口，而且包含其他方法，所以不能說新舊類型完全相同。  以空調為例，假設房間里已經安裝好了制冷設備的控制器，即你有了控制制冷設備的接口。想象一下，現在空調壞了，你重新安裝了一個既制冷又制熱的熱力泵。熱力泵就像是一個（is-like-a）空調，但它可以做更多。因為當初房間的控制系統被設計成只能控制制冷設備，所以它只能與新對象(熱力泵)的制冷部分通信。新對象的接口已經擴展了，現有控制系統卻只知道原來的接口，一旦看到這個設計，你就會發現，作為基類的制冷系統不夠一般化，應該被重新命名為"溫度控制系統"，也應該包含制熱功能，這樣的話，我們就可以使用替代原則了。上圖反映了在現實世界中進行設計時可能會發生的事情。 當你看到替代原則時，很容易會認為純粹替代是唯一可行的方式，并且使用純粹替代的設計是很好的。但有些時候，你會發現必須得在派生(擴展)類中添加新方法(提供新的接口)。只要仔細審視，你可以很明顯地區分兩種設計方式的使用場合。