關於Java中的繼續和組合的一個毛病應用的例子

關於Java中的繼續和組合的一個毛病應用的例子。本站提示廣大學習愛好者：（關於Java中的繼續和組合的一個毛病應用的例子）文章只能為提供參考，不一定能成為您想要的結果。以下是關於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 key
private int id;

很罕見吧，然則我在現實任務中碰到過很多的同事，體系界說一個稱號能夠為BaseModel或許RootModel的類，把下面的屬性id放在外面，然後全部項目中一切的model都繼續這個BaseModdel類。不曉得你們能否碰到過如許的同事？你們覺的如許寫能有甚麼利益和害處呢？

先說利益吧，假如非要說能帶來甚麼利益的話，除少敲幾下鍵盤，在子類中少些了這些屬性之外，沒看見有啥本質性的利益。然則卻為項目後續的保護帶來了很費事的工作。

然後說這類寫法的潛伏成績吧：

某一天，由於一些緣由，你想找子類A（繼續了BaseModel）中的屬性id在項目中的哪些處所應用

機靈的你闇練的應用起了IDE中的find usages,然後你就會發明你找到的應用地位異常的多，並且很多多少壓根不是你關懷的。然則沒方法，你也搜刮到了其他的繼續了BaseModel的類的屬性id的應用地位。假如項目不年夜，能夠搜刮到的闇練比擬少，假如項目年夜了一點呢？當搜刮闇練跨越了50處，你接上去會怎樣做？

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

若何防止湧現這類情形呢，那就是不要應用相似這類BaseModel的方法來應用屬性繼續。固然為了嚴謹時代，我照樣須要具體說一下這個意思，我並沒有完整否決屬性繼續哦，明白一下：

我否決的是全部項目一切的model繼續一個BaseModel，然後把公用屬性放在BaseModel中

的這類設法主意，留意是全部項目標

跋文
下面的不和教材的例子我小我常常會碰見，所以零丁拿出來講一下，我不肯定在年夜家的項目中能否湧現過這類情形。橫豎我曾經被同事的這類寫法坑過很多多少回了。

至於「組合」和「繼續」其他相干的罕見毛病，我臨時還沒想好（至多我覺的應當沒人會犯），假如我後續想清晰了，或許讀者同伙們有其他的建議願望可以留言交換一下哈。