Java基础 : 浅谈代码重构 - 继承与多态

改进代码重构 :: 继承与多态

现在我们有这么一个案例,有一个 资源管理仓库,里面存放CD、DVD。

继承

CD、DVD两个类都有大量相似的地方:成员变量、相似的成员函数,例如CD、DVD:
都有以下变量和函数
title、content(music/video)、author(artist/ director)、playTime;
print()打印内容信息

大量的代码复制 -- 代码质量不良的表现,将来会出现如下问题:

  • 维护代码不容易:一处修改,处处都要修改,如果print()没写好要修改,则我们复制粘贴过的地方,都需要修改;
  • 扩展性低:在CD、DVD的基础上,增加一个MP3播放器,则需要再拷贝复制大量重复代码。

而我们希望,只需 一处修改!

通过继承,将共同的部分抽象到一个父类里面,例如Medium类。该类有CD、DVD共同拥有的title、content、author、palytime等变量,也有一个print()的函数

当新增一个MP3类的时候,因为mp3和cd、dvd一样都是数字媒体的存储载体,存储的是歌曲,所以和cd十分相似,都有title、content等,也需要print()函数打印出内容信息。于是我们通过继承于Medium类,获得父类属性,只需要增加mp3特有的属性即可,如电量。如此,我们编写mp3类的时候,只需要写上一个 battery属性即可完成,既可以获得所需属性,又不需要复制粘贴。

当需要增加一个共同属性如出版公司company的时候,只需要在父类item.class中加入company字段,其子类cd/dvd/mp3均拥有了该属性,不再需要像起初那样每个子类都需要复制粘贴一次。

看,是不是可复用性、拓展性都大大提高了。
不说了,我也要回去封装重构我的Activity类了。


多态

我个人认为多态是提高代码兼容性的。

资源仓库类 中,只需要一个 ArrayList< Medium > 则可以存放 cd、dvd、mp3了,因为Medium是他们的父类,存在 is-a 关系。而不需要为每个子类添加一个ArrayList,
当有新存储载体进入仓库时,也不需要为该类去修改 资源仓库类 去添加一个新的ArrayList成员。

深入一点
为什么cd、dvd是Medium的子类,其他类中就能使用Medium引用收cd、dvd呢?
资源仓库类里面只有操作Medium的代码,如ArrayList< Medium >,为什么就能存cd呢,要是仅仅说cd是Medium的子类这一个理由太难说服我这颗木脑袋了。

这是一个用与不用的问题:当仅仅是将 cd 的引用 赋给 Medium变量,你说cd是Medium就是Medium,也没办法证明嘛,当使用到时,如medium.print()。那么,如果cd有print(),则可以执行,相信你的确是个Medium实例。当cd继承自Medium时,就已经获得了Medium的遗产–print()函数,所以编译器在执行过程中始终能调用到这个对象引用的和Medium一样的函数与变量。

也就是说,编译器并不管 当前变量引用的实例是否和变量声明的类是否是同一个,他只管执行声明变量类型所拥有的成员和方法。有就不报错,没有就报错。所以,如果Child类继承了Parent类,就拥有了Parent类的成员和方法。而以Parent类声明的变量只能执行Parent拥有的方法,所以实际执行Child对象时,能成功执行Parent类所声明的方法。

多态就这么诞生了,这就是多态的特性

/* * 原始需求背景: * 网宿CDN要按月收取客户的服务费用,根据流量的大小、 * 服务的类型等,收取不同的费用,收费规则如下: * web应用:1000元/M * 流媒体应用:1000元/M*0.7 * 下载应用:1000元/M*0.5 * 月末打印报表时,要罗列每个用户每个频道的费用、客户总费用, * 还要打印该客户的重要性指数,重要性指数=网页流/100+下载流量/600; * * 需求变更场景: * 系统已经开发出来了,接下来,运维部门现在希望对系统做一点修改, * 首先,他们希望能够输出xml,这样可以被其它系统读取和处理,但是, * 这段代码根本不可能在输出xml的代码中复用report()的任何行为,唯一 * 可以做的就是重写一个xmlReport(),大量重复report()中的行为,当然, * 现在这个修改还不费劲,拷贝一份report()直接修改就是了。 * 不久,成本中心又要求修改计费规则,于是我们必须同时修改xmlReport() * 和report(),并确保其一致性,当后续还要修改的时候,复制-黏贴的问题就 * 浮现出来了,这造成了潜在的威胁。 * 再后来,客服部门希望修改服务类型和用户重要性指数的计算规则, * 但还没决定怎么改,他们设想了几种方案,这些方案会影响用户的计费规则, * 程序必须再次同时修改xmlReport()和report(),随着各种规则变得越来越复杂, * 适当的修改点越 来越难找,不犯错误的机会越来越少。 * 现在,我们运用所学的OO原则和方法开始进行改写吧。 */
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

忘词木头人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值