关于Java中的继承和组合的一个错误使用的例子

时间:2021-05-19

相信绝大多数人都比较熟悉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中

的这种想法,注意是整个项目的

后记
上面的反面教材的例子我个人经常会碰见,所以单独拿出来说一下,我不确定在大家的项目中是否出现过这种情况。反正我已经被同事的这种写法坑过好多回了。

至于「组合」和「继承」其他相关的常见错误,我暂时还没想好(至少我觉的应该没人会犯),如果我后续想清楚了,或者读者朋友们有其他的建议希望可以留言交流一下哈。

声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。

相关文章