您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
跳出面向对象思想(一) 继承
 

来源:casatwy 发布于:2016-6-20

  2764  次浏览      19
 

简述

我会在这篇这一系列文章中谈谈面向对象思想的几个部分,并且给出对应的解决方案,这些解决方案有些是用面向过程的思路解决的,有些也还是停留在面向对象中。到最后我会给大家一个比较,然后给出结论。

上下文规范

在进一步地讨论这些概念之前,我需要跟大家达成一个表达上的共识,我会采用下面的语法来表达对象相关的信息:

来,我们谈谈对象

面向对象思想三大支柱:继承、封装、多态。这篇文章说的是继承。当然面向对象和面向过程都会有好有坏,但是做决定的时候,更多地还是去权衡值得不值得放弃。关于这样的立场问题,我都会给出非常明确的倾向,不会跟你们打太极。

如果说这个也好那个也好,那还发表毛个观点,那叫没有观点。

继承

继承从代码复用的角度来说,特别好用,也特别容易被滥用和被错用。不恰当地使用继承导致的最大的一个缺陷特征就是高耦合。

在这里我要补充一点,耦合是一个特征,虽然大部分情况是缺陷的特征,但是当耦合成为需求的时候,耦合就不是缺陷了。耦合成为需求的例子在后面会提到。

我们来看下面这个场景:

有一天,产品经理Yuki说:

我们不光首页要有一个搜索框,在进去的这个页面,也要有一个搜索框,只不过这个搜索框要多一些功能,它是可以即时给用户搜索提示的。

Casa接到这个任务,他研究了一下代码,说:OK,没问题~

Casa知道代码里已经有了一个现成的搜索框,Casa立刻从HOME_SEARCH_BAR派生出PAGE_SEARCH_BAR

嗯,目前事情进展到这里还不错:

过了几天,产品经理Yuki要求:

用户收藏的东西太多了,我们的app需要有一个本地搜索的功能。

Casa轻松通过方法覆盖摆平了这事儿:

app上线一段时间之后,UED不知哪根筋搭错了,决定要修改搜索框的UI,UED跟Casa说:

把HOME_SEARCH_BAR的样式改成这样吧,里面PAGE_SEARCH_BAR还是老样子就OK。

Casa表示这个看似简单的修改其实很蛋碎,HOME_SEARCH_BAR的样式一改,PAGE_SEARCH_BAR和LOCAL_SEARCH_BAR都会改变,怎么办呢? 与其每个手工修一遍,Casa不得已只能给HOME_SEARCH_BAR添加了一个函数:initWithStyle()

于是代码里面就出现了各种init()和initWithStyle()混用的情况。

无所谓了,先把需求应付过去再说。

Casa这么想。

有一天,另外一个team的leader来对Casa抱怨:

搞什么玩意儿?为毛我要把LOCAL_SEARCH_BAR独立出来还特么连带着把那么多文件都弄出来?我就只是想要个本地搜索的功能而已!!

这是因为LOCAL_SEARCH_BAR依赖于它的父类HOME_SEARCH_BAR,然而HOME_SEARCH_BAR本身也带着API相关的对象,同时还有数据解析的对象。 也就是说,要想把LOCAL_SEARCH_BAR移植给另外一个TEAM,拔出萝卜带出泥,差不多整个Networking框架都要移植过去。 嗯,Casa又要为了解耦开始一个不眠之夜了~

以上是典型的错误使用继承的案例,虽然继承是代码复用的一种方案,但是使用继承仍然是需要好好甄别代码复用的方式的,不是所有场景的代码复用都适用于继承。

继承是紧耦合的一种模式,主要的体现就在于牵一发动全身。

第一种类型的问题是改了一处,到处都要改,但解决方案还算方便,多添加一个特定的函数(initWithStyle())就好了。只是代码里面难看一点。

第二种类型的问题是代码复用的时候,要跟着把父类以及父类所有的相关依赖也复制过去,高耦合在复用的时候造成了冗余

对于这样的问题,业界其实早就给出了解决方案:用组合替代继承。将Textfield和search模块拆开,然后通过定义好的接口进行交互,一般来说可以选择Delegate模式来交互。

解决方案:

这样一来,搜索框和搜索逻辑分别形成了两个不同的组件,分别在HOME_SEARCH_BAR, PAGE_SEARCH_BAR, LOCAL_SEARCH_BAR中以不同的形态组合而成。 textField和SEARCH_LOGIC<search_protocol>之间通过delegate的模式进行数据交互。 这样就解决了上面提到的两种类型的问题。 大部分我们通过代码复用来选择继承的情况,其实都是变成组合比较好。 因此我在团队中一直在推动使用组合来代替继承的方案。 那么什么时候继承才有用呢?

纠结了一下,貌似实在是没什么地方非要用继承不可的。但事实上使用继承,我们得要分清楚层次,使用继承其实是如何给一类对象划分层次的问题。在正确的继承方式中,父类应当扮演的是底层的角色,子类是上层的业务。举两个例子:

这里是有非常明确的层次关系的,我在这里也顺便提一下使用继承的3大要点:

父类只是给子类提供服务,并不涉及子类的业务逻辑

层级关系明显,功能划分清晰,父类和子类各做各的。

父类的所有变化,都需要在子类中体现,也就是说此时耦合已经成为需求

此时我们回过头来看为什么HOME_SEARCH_BAR,PAGE_SEARCH_BAR,LOCAL_SEARCH_BAR采用继承的方案是不恰当的:

他们的父类是HOME_SEARCH_BAR,父类不只提供了服务,也在一定程度上影响了子类的业务逻辑。派生出的子类也是为了要做搜索,虽然搜索的逻辑不同,但是互相涉及到搜索这一块业务了。

子类做搜索,父类也做搜索,虽然处理逻辑不同,但是这是同一个业务,与父类在业务上的联系密切。在层级关系上,HOME_SEARCH_BAR和其派生出的LOCAL_SEARCH_BAR, PAGE_SEARCH_BAR其实是并列关系,并不是上下层级关系。

由于这里所谓的父类和子类其实是并列关系而不是父子关系,且并没有需要耦合的需求,相反,每个派生子类其实都不希望跟父类有耦合,此时耦合不是需求,是缺陷。

总结

可见,代码复用也是分类别的,如果当初只是出于代码复用的目的而不区分类别和场景,就采用继承是不恰当的。我们应当考虑以上3点要素看是否符合,才能决定是否使用继承。就目前大多数的开发任务来看,继承出现的场景不多,主要还是代码复用的场景比较多,然而通过组合去进行代码复用显得要比继承麻烦一些,因为组合要求你有更强的抽象能力,继承则比较符合直觉。然而从未来可能产生的需求变化和维护成本来看,使用组合其实是很值得的。另外,当你发现你的继承超过2层的时候,你就要好好考虑是否这个继承的方案了,第三层继承正是滥用的开端。确定有必要之后,再进行更多层次的继承。



   
2764 次浏览       19
最新活动计划
软件架构设计方法、案例与实践 8-23[特惠]
Linux内核编程及设备驱动 8-15[北京]
Python、数据分析与机器学习 8-23[特惠]
嵌入式软件架构设计 8-22[线上]
QT应用开发 9-5[北京]

如何向妻子解释OOD
OOAD与UML笔记
UML类图与类的关系详解
UML统一建模语言初学
总结一下领域模型的验证
基于 UML 的业务建模


面向对象的分析设计
基于UML的面向对象分析设计
UML + 嵌入式系统分析设计
关系数据库面向OOAD设计
业务建模与业务架构
使用用例进行需求管理


某航空IT部门 业务分析与业务建模
联想 业务需求分析与建模
北京航管科技 EA工具与架构设计
使用EA和UML进行嵌入式系统分析
全球最大的茶业集团 UML系统分析
华为 基于EA的嵌入式系统建模
水资源服务商 基于EA进行UML建模
更多...