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

相信绝大多数人都比较熟悉Java中的「继承」和「组合」这两个东西，本篇文章就主要就这两个话题谈论一下。如果我某些地方写的不对，或者比较幼稚，论证不清晰，欢迎大家留言指正。

什么是「组合」和「继承」

假设有2个class：A和B:

• 如果class A extendsB 那么我们就说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中

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

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

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