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

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

假设有2个class：[code]A[/code]和[code]B[/code]: [list] [*]如果class A [code]extends[/code] B 那么我们就说A继承B，A是子类，B是父类，这种情况就是继承。[/*] [*]如果A中有一个属性的类型为B，那么我们就说这种情况就是组合。[/*] [/list]

分别在什么情况下使用

回想一些我们一般会在什么情况下考虑这两个东西呢？我大致想了一下，往往会有如下的场景： [list] [*]公用代码[/*] [*]为了表明事物之间的「共性」或者说仅仅为了「泛型」，抽取[code]abstract class[/code]或者[code]interface[/code][/*] [/list] 我想来想去，好像真的只有这两种情况了，但是这两种情况有特别的有关联，比如说[b]公用代码[/b]这个事情，其实[code]abstract class[/code]和[code]interface[/code]（Java 8中的default method）都可以达到。 好吧，说了这么多屁话，我就直接抛出我的观点吧，欢迎拍砖： [list] [*]如果你仅仅想公用代码，而且使用这些公用代码的class或者method并没有很明显的联系，那么就请使用组合。[/*] [*]如果若干个class或者其method有比较明显的联系，那么请抽取一个[code]abstract class[/code]或者[code]interface[/code][/*] [*][b]慎用「属性继承」[/b]的特性，建议子类明确复写所需要的父类的属性。这一点尤为重要，后续会有一个例子来说明这种情况的不利面。[/*] [/list]

反面教材

比较常见的一个例子：我们在实际的项目中，往往会定义好的的[code]POJO[/code]或者说[code]model[/code]，而这些model往往都会有一些名词和类型相同的属性，比如：

[code]// db table primary key
private int id;[/code]

很常见吧，但是我在实际工作中遇到过不少的同事，系统定义一个名称可能为[code]BaseModel[/code]或者[code]RootModel[/code]的类，把上面的属性[code]id[/code]放在里面，然后整个项目中所有的model都继承这个BaseModdel类。不知道你们是否遇到过这样的同事？你们觉的这样写能有什么好处和坏处呢？ 先说好处吧，如果非要说能带来什么好处的话，除了少敲几下键盘，在子类中少些了这些属性以外，没看见有啥[b]实质性[/b]的好处。但是却为项目后续的维护带来了很麻烦的事情。 然后说这种写法的潜在问题吧： [quote] 某一天，因为一些原因，你想找子类A（继承了BaseModel）中的属性[code]id[/code]在项目中的哪些地方使用 [/quote] 机智的你熟练的使用起了IDE中的[code]find usages[/code],然后你就会发现你找到的使用位置非常的多，而且好多压根不是你关心的。但是没办法，你也搜索到了其他的继承了BaseModel的类的属性id的使用位置。如果项目不大，可能搜索到的熟练比较少，如果项目大了一点呢？当搜索熟练超过了50处，你接下来会怎么做？ [list] [*]一个一个看搜索出来的代码，看了十几二十个开始喷，然后继续一个一个往下找？[/*] [*]直接开始喷，然后在一个一个看搜索出来的代码？[/*] [/list] 如何避免出现这种情况呢，那就是不要使用类似这种[code]BaseModel[/code]的方式来使用属性继承。当然为了严谨期间，我还是需要详细说一下这个意思，我并没有完全反对属性继承哦，明确一下： [b]我反对的是整个项目所有的model继承一个BaseModel，然后把公用属性放在BaseModel中[/b] 的这种想法，注意是整个项目的 后记 上面的反面教材的例子我个人经常会碰见，所以单独拿出来说一下，我不确定在大家的项目中是否出现过这种情况。反正我已经被同事的这种写法坑过好多回了。 至于「组合」和「继承」其他相关的常见错误，我暂时还没想好（至少我觉的应该没人会犯），如果我后续想清楚了，或者读者朋友们有其他的建议希望可以留言交流一下哈。