关于Java中的继承和组合的一个错误使用的例子
2016-03-21 12:56 Rollen Holt 阅读(1703) 评论(0) 编辑 收藏 举报关于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中
的这种想法,注意是整个项目的
后记
上面的反面教材的例子我个人经常会碰见,所以单独拿出来说一下,我不确定在大家的项目中是否出现过这种情况。反正我已经被同事的这种写法坑过好多回了。
至于「组合」和「继承」其他相关的常见错误,我暂时还没想好(至少我觉的应该没人会犯),如果我后续想清楚了,或者读者朋友们有其他的建议希望可以留言交流一下哈。
==============================================================================
本博客已经废弃,不在维护。新博客地址:http://wenchao.ren
我喜欢程序员,他们单纯、固执、容易体会到成就感;面对压力,能够挑灯夜战不眠不休;面对困难,能够迎难而上挑战自我。他
们也会感到困惑与傍徨,但每个程序员的心中都有一个比尔盖茨或是乔布斯的梦想“用智慧开创属于自己的事业”。我想说的是,其
实我是一个程序员
==============================================================================