關於Java中的繼承和組合的一個錯誤使用的例子

相信絕大多數人都比較熟悉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 keyprivate int id;

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

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

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

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

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

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

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

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

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

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

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