注册
登录
本文作者：田伟宇（GitCafe 用户） 博客地址：http://casatwy.com/ 简述 我会在这篇这一系列文章中谈谈面向对象思想的几个部分，并且给出对应的解决方案，这些解决方案有些是用面向过程的思路解决的，有些也还是停留在面向对象中。到最后我会给大家一个比较，然后给出结论。 上下文规范 在进一步地讨论这些概念之前，我需要跟大家达成一个表达上的共识，我会采用下面的语法来表达对象相关的信息： 来，我们谈谈对象 面向对象思想三大支柱：继承、封装、多态。这篇文章说的是继承。当然面向对象和面向过程都会有好有坏，但是做决定的时候，更多地还是去权衡值得不值得放弃。关于这样的立场问题，我都会给出非常明确的倾向，不会跟你们打太极。 如果说这个也好那个也好，那还发表毛个观点，那叫没有观点。 继承 继承从代码复用的角度来说，特别好用，也特别容易被滥用和被错用。不恰当地使用继承导致的最大的一个缺陷特征就是高耦合。在这里我要补充一点，耦合是一个特征，虽然大部分情况是缺陷的特征，但是当耦合成为需求的时候，耦合就不是缺陷了。耦合成为需求的例子在后面会提到。 我们来看下面这个场景： 有一天，产品经理 Yuki 说：
Casa 接到这个任务，他研究了一下代码，说：OK，没问题~ Casa 知道代码里已经有了一个现成的搜索框，立刻从 HOME_SEARCH_BAR 派生出 PAGE_SEARCH_BAR。嗯，目前事情进展到这里还不错： 过了几天，产品经理 Yuki 要求：
Casa 轻松通过方法覆盖摆平了这事儿： app 上线一段时间之后，UED 不知哪根筋搭错了，决定要修改搜索框的 UI，UED 跟 Casa 说：
Casa 表示这个看似简单的修改其实很蛋碎，HOME_SEARCH_BAR 的样式一改，PAGE_SEARCH_BAR 和 LOCAL_SEARCH_BAR 都会改变，怎么办呢？ 与其每个手工修一遍，Casa 不得已只能给 HOME_SEARCH_BAR 添加了一个函数：initWithStyle() 于是代码里面就出现了各种 init() 和 initWithStyle() 混用的情况。 无所谓了，先把需求应付过去再说。 Casa 这么想。 有一天，另外一个 team 的 leader 来对 Casa 抱怨：
这是因为 LOCAL_SEARCH_BAR 依赖于它的父类 HOME_SEARCH_BAR，然而 HOME_SEARCH_BAR 本身也带着 API 相关的对象，同时还有数据解析的。也就是说，要把 LOCAL_SEARCH_BAR 移植给另外一个 TEAM，拔出萝卜带出泥，差不多整个 Networking 框架都要移植过去。 嗯，Casa 又要为了解耦开始一个不眠之夜了～ 以上是典型的错误使用继承的案例，虽然继承是代码复用的一种方案，但是使用继承仍然是需要好好甄别代码复用的方式的，不是所有场景的代码复用都适用于继承。 继承是紧耦合的一种模式，主要的体现就在于牵一发动全身。
对于这样的问题，业界其实早就给出了解决方案：用组合替代继承。将 Textfield 和 search 模块拆开，然后通过定义好的接口进行交互，一般来说可以选择 Delegate 模式来交互。 解决方案： 这样一来，搜索框和搜索逻辑分别形成了两个不同的组件，分别在 HOME_SEARCH_BAR、PAGE_SEARCH_BAR 和 LOCAL_SEARCH_BAR 中以不同的形态组合而成。 TextField 和 SEARCH_LOGIC |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
