很多人都知道，博主最近在更新一個專題——《解讀阿里巴巴Java開發手冊》，本文是該專題中的另外一篇。

從學習Java的第一天起，我們就知道Java是一種面嚮物件語言，而學習Java的第二天，我們就知道了面向物件的三大基本特性是：封裝、繼承、多型。

所以，對於很多開發者來說，繼承肯定都是不陌生的。但是，繼承一定適合所有的場景嗎？毫無忌諱的使用繼承來做程式碼擴充套件真的好嗎？

為什麼《阿里巴巴Java開發手冊》中有一條規定：謹慎使用繼承的方式進行擴充套件，優先使用組合的方式實現。

本文就來針對這些問題，簡單分析一下。

面向物件的複用技術

每個人在剛剛學習繼承的時候都會或多或少的有這樣一個印象：繼承可以幫助我實現類的複用。所以，很多開發人員在需要複用一些程式碼的時候會很自然的使用類的繼承的方式，因為書上就是這麼寫的（老師就是這麼教的）。但是，其實這樣做是不對的。長期大量的使用繼承會給程式碼帶來很高的維護成本。

前面提到複用，這裡就簡單介紹一下面向物件的複用技術。

複用性是面向物件技術帶來的很棒的潛在好處之一。如果運用的好的話可以幫助我們節省很多開發時間，提升開發效率。但是，如果被濫用那麼就可能產生很多難以維護的程式碼。

作為一門面向物件開發的語言，程式碼複用是Java引人注意的功能之一。Java程式碼的複用有繼承，組合以及代理三種具體的表現形式。

繼承

繼承（Inheritance）是一種聯結類與類的層次模型。指的是一個類（稱為子類、子介面）繼承另外的一個類（稱為父類、父介面）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者介面與介面之間最常見的關係。

繼承是一種is-a關係。如蘋果是水果，狗是動物，哈士奇是狗。

組合

組合(Composition)體現的是整體與部分、擁有的關係。

組合是一種has-a的關係。如汽車有一個發動機，學校有一個老師等。

組合與繼承的區別

首先，從類的關係確定時間點上，組合和繼承是有區別的：

繼承，在寫程式碼的時候就要指名具體繼承哪個類，所以，在編譯期就確定了關係。並且從基類繼承來的實現是無法在執行期動態改變的，因此降低了應用的靈活性。

組合，在寫程式碼的時候可以採用面向介面程式設計。所以，類的組合關係一般在執行期確定。

另外，程式碼複用方式上也有一定區別：

繼承結構中，父類的內部細節對於子類是可見的。所以我們通常也可以說通過繼承的程式碼複用是一種白盒式程式碼複用。

如果基類的實現發生改變，那麼派生類的實現也將隨之改變。這樣就導致了子類行為的不可預知性。

組合是通過對現有的物件進行拼裝（組合）產生新的、更復雜的功能。因為在物件之間，各自的內部細節是不可見的，所以我們也說這種方式的程式碼複用是黑盒式程式碼複用。

因為組閤中一般都定義一個型別，所以在編譯期根本不知道具體會呼叫哪個實現類的方法。

最後，Java中不支援多繼承，而組合是沒有限制的。就像一個人只能有一個父親，但是他可以有很很多輛車。

優缺點對比

為什麼組合優於繼承

相信很多人都知道面向物件中有一個比較重要的原則『多用組合、少用繼承』或者說『組合優於繼承』。從前面的介紹已經優缺點對比中也可以看出，組合確實比繼承更加靈活，也更有助於程式碼維護。

所以，**建議在同樣可行的情況下，優先使用組合而不是繼承。**因為組合更安全，更簡單，更靈活，更高效。

注意，並不是說繼承就一點用都沒有了，前面說的是【在同樣可行的情況下】。有一些場景還是需要使用繼承的，或者是更適合使用繼承。

另外，除了《阿里巴巴Java開發手冊》，在很多其他資料中也有關於組合和繼承的介紹和使用約束：

繼承要慎用，其使用場合僅限於你確信使用該技術有效的情況。一個判斷方法是，問一問自己是否需要從新類向基類進行向上轉型。如果是必須的，則繼承是必要的。反之則應該好好考慮是否需要繼承。《Java程式設計思想》

只有當子類真正是超類的子型別時，才適合用繼承。換句話說，對於兩個類A和B，只有當兩者之間確實存在is-a關係的時候，類B才應該繼續類A。《Effective Java》