相信絕大多數人都比較熟悉Java中的「繼承」和「組合」這兩個東西，本篇文章就主要就這兩個話題談論一下。如果我某些地方寫的不對，或者比較幼稚，論證不清晰，歡迎大家留言指正。

什么是「組合」和「繼承」

假設有2個class：A和B:

• 如果class A extends B 那么我們就說A繼承B，A是子類，B是父類，這種情況就是繼承。
• 如果A中有一個屬性的類型為B，那么我們就說這種情況就是組合。

分別在什么情況下使用

回想一些我們一般會在什么情況下考慮這兩個東西呢？我大致想了一下，往往會有如下的場景：

• 公用代碼
• 為了表明事物之間的「共性」或者說僅僅為了「泛型」，抽取abstract class或者interface

我想來想去，好像真的只有這兩種情況了，但是這兩種情況有特別的有關聯，比如說公用代碼這個事情，其實abstract class和interface（Java 8中的default method）都可以達到。

好吧，說了這么多屁話，我就直接拋出我的觀點吧，歡迎拍磚：

• 如果你僅僅想公用代碼，而且使用這些公用代碼的class或者method并沒有很明顯的聯系，那么就請使用組合。
• 如果若干個class或者其method有比較明顯的聯系，那么請抽取一個abstract class或者interface
• 慎用「屬性繼承」的特性，建議子類明確復寫所需要的父類的屬性。這一點尤為重要，后續會有一個例子來說明這種情況的不利面。

反面教材

比較常見的一個例子：我們在實際的項目中，往往會定義好的的POJO或者說model，而這些model往往都會有一些名詞和類型相同的屬性，比如：

// db table primary key
private int id;

很常見吧，但是我在實際工作中遇到過不少的同事，系統定義一個名稱可能為BaseModel或者RootModel的類，把上面的屬性id放在里面，然后整個項目中所有的model都繼承這個BaseModdel類。不知道你們是否遇到過這樣的同事？你們覺的這樣寫能有什么好處和壞處呢？

先說好處吧，如果非要說能帶來什么好處的話，除了少敲幾下鍵盤，在子類中少些了這些屬性以外，沒看見有啥實質性的好處。但是卻為項目后續的維護帶來了很麻煩的事情。

然后說這種寫法的潛在問題吧：

某一天，因為一些原因，你想找子類A（繼承了BaseModel）中的屬性id在項目中的哪些地方使用

機智的你熟練的使用起了IDE中的find usages,然后你就會發現你找到的使用位置非常的多，而且好多壓根不是你關心的。但是沒辦法，你也搜索到了其他的繼承了BaseModel的類的屬性id的使用位置。如果項目不大，可能搜索到的熟練比較少，如果項目大了一點呢？當搜索熟練超過了50處，你接下來會怎么做？

• 一個一個看搜索出來的代碼，看了十幾二十個開始噴，然后繼續一個一個往下找？
• 直接開始噴，然后在一個一個看搜索出來的代碼？

如何避免出現這種情況呢，那就是不要使用類似這種BaseModel的方式來使用屬性繼承。當然為了嚴謹期間，我還是需要詳細說一下這個意思，我并沒有完全反對屬性繼承哦，明確一下：

我反對的是整個項目所有的model繼承一個BaseModel，然后把公用屬性放在BaseModel中

的這種想法，注意是整個項目的

后記
上面的反面教材的例子我個人經常會碰見，所以單獨拿出來說一下，我不確定在大家的項目中是否出現過這種情況。反正我已經被同事的這種寫法坑過好多回了。

至于「組合」和「繼承」其他相關的常見錯誤，我暫時還沒想好（至少我覺的應該沒人會犯），如果我后續想清楚了，或者讀者朋友們有其他的建議希望可以留言交流一下哈。