iOS代码耦合的处理

EllBrunette 7年前
   <p>耦合是每个程序员都必须面对的话题,也是容易被忽视的存在,怎么处理耦合关系到我们最后的代码质量。今天Peak君和大家聊聊耦合这个基本功话题,一起捋一捋iOS代码中处理耦合的种种方式及差异。</p>    <h3>简化场景</h3>    <p>耦合的话题可大可小,但原理都是相通的。为了方便讨论,我们先将场景进行抽象和简化,只讨论两个类之间的耦合。</p>    <p>假设我们有个类Person,需要喝水,根据职责划分,我们需要另一个类Cup来完成喝水的动作,代码如下:</p>    <pre>  <code class="language-objectivec">//Person.h  @interface Person : NSObject  - (void)drink;  @end    //Cup.h  @interface Cup : NSObject  - (id)provideWater;  @end</code></pre>    <p>很明显,Person和Cup之间要配合完成喝水的动作,是无论如何都会产生耦合的,我们来看看在Objective C下都有哪些耦合的方式,以及不同耦合方式对以后代码质量变化的影响。</p>    <h3>方式一:.m引用</h3>    <p>这种方式直接在.m文件中导入Cup.h,同时生成临时的Cup对象来调用Cup中的方法。代码如下:</p>    <pre>  <code class="language-objectivec">#import "Person.h"  #import "Cup.h"    @implementation Person    - (void)drink {      Cup* c = [Cup new];        id water = [c provideWater];      [self sip:water];  }    - (void)sip:(id)water  {      //sip water  }    @end</code></pre>    <p>这应该是不少同学会选择的做法,要用到某个类的功能,就import该类,再调用方法,功能完成提交测试一气呵成。</p>    <p>这种方式初看起来没什么毛病,但有个弊端:Person与Cup的耦合被埋进了Person.m文件的方法实现中,而.m文件一般都是业务逻辑代码的重灾区,当Person.m的代码量膨胀之后,如果Person类交由另一位工程师来维护,那这位新接手的同学无法从Person.h中一眼看出Person类和哪些类之间有交互,即使在Person.m中看drink的声明也没有任何线索,要理清楚的话,只能把Person.m文件从头到尾读一遍,对团队效率的影响可想而知。</p>    <h3>方式二:.h Property</h3>    <p>既然直接在.m中引用会导致耦合不清晰,我们可以将耦合的部分放入Property中,代码如下:</p>    <pre>  <code class="language-objectivec">//Person.h  @interface Person : NSObject  @property (nonatomic, strong) Cup*                 cup;  - (void)drink;  @end    //Person.m  @implementation Person  - (void)drink {      id water = [self.cup provideWater];      [self sip:water];  }    - (void)sip:(id)water  {      //sip water  }  @end</code></pre>    <p>这样,我们只需要扫一眼Person.h就能明白,Person类对哪些类产生了依赖,比直接在.m中引用清晰多了。</p>    <p>不知道大家有没有好奇过,为什么在Objective C中会有.h文件的存在,为什么不像Java,Swift一样一个文件代表一个类?使用.h文件有利有弊。</p>    <p>.h文件最大的意义在于将 <strong>声明</strong> 和 <strong>实现</strong> 相隔离。声明是告诉外部我支持哪些功能,实现是支撑这些功能背后的代码逻辑。在我们阅读一个类的.h文件的时候,它最主要的作用是透露两个信息:</p>    <ul>     <li>我(Person类)依赖了哪些外部元素</li>     <li>我(Person类)提供哪些接口供外部调用</li>    </ul>    <p>所以.h文件应该是我们代码耦合的关键所在,当我们犹豫一个类的Property要不要放到.h文件中去声明时,要思考这个Property是不是必须暴露给外部。一旦暴露到.h文件中,就增加了依赖和耦合的几率。有时候Review代码,只要看.h文件是否清晰,就大概能猜测这个类设计者的水平。</p>    <p>当我们把Cup类做为Person的Property声明时,就表明Person与Cup之间存在必要的依赖,我们把这种依赖放到头文件中来,起到一目了然的效果。这比方式一清晰了不少,但有另一个问题,Cup暴露出去以后,外部元素可以随意修改,当内部执行drink的时候,可能另一个线程将cup置空了,影响正常的业务流程。</p>    <h3>方式三:.h ReadOnly Property</h3>    <p>方式二中,Person类在对Cup产生依赖的同时,也承担了cup随时被外部修改的风险。当然做直观的做法是将Cup类作为ReadOnly的property,同时提供一个对外的setter:</p>    <pre>  <code class="language-objectivec">//Person.h  @interface Person : NSObject  @property (nonatomic, strong, readonly) Cup*                 cup;  - (void)setPersonCup:(Cup*)cup;  - (void)drink;  @end</code></pre>    <p>有同学可能会问,这和上面的做法有什么区别,不一样都有读写的接口吗?最大的区别是增加了检查和干扰的入口。</p>    <p>当我Debug的时候,经常需要检查某个Propery到底是被谁修改了,Setter中设置一个断点调试起来方便不少。同时,我们还可以使用Xcode的Caller机制,查看当前Setter都被那些外部类调用了,分析类与类之间的关联是很有帮助。</p>    <p>Person.m中Setter方法还提供了我们拓展功能的入口,比如我们需要在Setter中增加多线程同步Lock,当Person.m中的其他方法在使用Cup时,Setter必须等待完成才能执行。又比如我们可以在Setter中实现Copy On Write机制:</p>    <pre>  <code class="language-objectivec">//Person.m  - (void)setPersonCup:(Cup*)cup {      Cup* anotherCup = [cup copy];      _cup = anotherCup;  }</code></pre>    <p>这样,Person类就可以避免和外部类共享同一个Cup,杜绝使用同一个水杯的卫生问题 ;)</p>    <p>总之,单独的Setter方法让我们对代码有更大的掌控能力,也为后续接手维护你代码的同学带来了方便,利己利人。</p>    <h3>方式四:init 注入</h3>    <p>使用带Setter的Property虽然看上去好了不少,但Setter方法可以被任意外部类随时随刻调用,对于Person.m中使用Cup的方法来说,多少有些不安心,万一用着用着被别人改了呢?</p>    <p>为了避免被随意修改,我们可以采用init注入的方式,Objective C中的designated initializer正是为此而生:</p>    <pre>  <code class="language-objectivec">//Person.h  @interface Person : NSObject  - (instancetype)initWithCup:(Cup*)cup;  - (void)drink;  @end</code></pre>    <p>去掉Property,将Cup的设置放入init方法中,这样Person类对外就只提供一次机会来设置Cup,init之后,外部类就没有其他机会来修改Cup了。</p>    <p>这是使用最多,也是比较推荐的方式。只在对象被创建的时候,去建立与其他对象的关系,把可变性降低到一定程度。那这种方式是否也有什么缺点呢?</p>    <p>通过init的方式设置cup,杜绝了外部因素的影响,但如果内部持有了cup对象,那么内部的函数调用依然可以通过各种姿势与Cup类产生耦合,比如:</p>    <pre>  <code class="language-objectivec">//Person.m  @interface Person ()  @property (nonatomic, strong) Cup*                 myCup;  @end    @implementation Person  - (instancetype)initWithCup:(Cup*)cup {      self = [super init];      if (self) {          self.myCup = cup;      }      return self;  }    - (void)drinkWater {      id water = [self.myCup provideWater];      [self sip:water];  }    - (void)drinkMilk {      id milk = [self.myCup provideMilk];      [self sip:milk];  }    @end</code></pre>    <p>Person内部的方法可以通过Cup所有对外的接口来产生耦合,此时我们对于两个类之间的耦合,就主要靠对Cup.h头文件来解读了。如果Cup类设计合理,头文件结构清晰的话,这其实不算太糟糕的场景。那还有没有其他方式呢?</p>    <h3>方式五:parameter 注入</h3>    <p>用Property持有的方式,在Person对象的整个生命周期内,耦合的可能性一直存在,原因在于Property对于.m文件来说是全局可见的。我们可以用另一种方式让耦合只发生在单个方法内部,即parameter injection:</p>    <pre>  <code class="language-objectivec">//Person.h  @interface Person : NSObject  - (void)drink:(Cup*)cup;  @end    //Person.m  - (void)drink:(Cup*)cup {      id water = [cup provideWater];      [self sip:water];  }</code></pre>    <p>这种方式的好处在于:Person和Cup的耦合只发生在drink函数的内部,一旦函数调用结束,Person和Cup之间就结束了依赖关系。从时间和空间的跨度上来说,这种方式比持有Property风险更小。</p>    <p>可要是在Person中存在多处Cup的依赖,比如有drinkWater,drinkMilk,drinkCoffee等等,反而又不如Property直观方便了。</p>    <h3>方式六:单例引用</h3>    <p>单例的优劣有很多优秀的技术文章分析过了,Peak君只强调其中一点,也是平时review代码和Debug发现最多的问题缘由: <strong>单例中的状态共享</strong> 。</p>    <p>上面的例子中,我们可以把Cup做成单例,代码如下:</p>    <pre>  <code class="language-objectivec">//Person.m  - (void)drink {      id water = [[Cup sharedInstance] provideWater];      [self sip:water];  }</code></pre>    <p>这种方式产生的耦合不但和方式一同样隐蔽,而且是最容易导致代码降级的,随着版本的不停迭代,我们很有可能会得到下面的一个类关联图:</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/9a3abc91a8da52e420b5c217ffad9c77.png"></p>    <p>所有的对象都依赖于同一个对象的状态,所有的对象都对这个对象的状态拥有读写权限,最后的结果很有可能是到处打补丁修Bug,按下葫芦浮起瓢。</p>    <p>使用单例类似的场景很常见,比如我们在单例中持有某个用户的信息,在用户登出之后,忘记清除之前用户的信息就会导致奇怪的bug,而且单例一旦零散的分布在项目的各个角落,要逐一处理十分困难。</p>    <h3>方式七:继承</h3>    <p>继承是一种强耦合关系,网络上有不少关于继承(inheritance)和组合(compoisition)之间优劣的对比文章了,这里不做赘述。继承确实能在初期很方便的建立清晰的对象模型,重用和多态看着也很美妙,问题在于这种强耦合关系在理解上很容易产生分歧,比如什么样对象之间可以被确立为父子关系,哪些子类的行为可以放到父类中给其他子类使用,在多层继承的时候这些问题会变得更加复杂。所以Peak君建议尽可能的少用继承关系来描述对象,除非是一目了然毫无异议的父子关系。</p>    <p>我就不强行来一波父类定义来举例了,比如什么ObjectWithCup这类。</p>    <h3>方式八:runtime依赖</h3>    <p>使用runtime来处理耦合是Objective C独特的方式,而且耦合度非常之低,甚至可以说感觉不到耦合的存在,比如:</p>    <pre>  <code class="language-objectivec">//Person.m  - (void)drink:(id)obj  {      id water = nil;      SEL sel = NSSelectorFromString(@"provideWater");      if ([obj respondsToSelector:sel]) {          water = [obj performSelector:sel];      }      if (water) {        [self sip:water];      }  }</code></pre>    <p>既不需要导入Cup的头文件,也不需要知道Cup到底支持哪些方法。这种方式的问题也正是由于耦合度太低了,让开发者感知不到耦合的存在,感知不到类之间的关系。如果哪天有人把provideWater改写成getWater,drink方法如果没有同步到,Xcode编译时不会提示你,runtime也不会crash,但是业务流程却没有正常往下走了。</p>    <p>这也是为什么我们不推荐用Objective-C runtime的黑魔法去做业务,只是在无副作用的场景下去完成一些数据的获取操作,比如使用AOP去log日志。</p>    <h3>方式九:protocol依赖</h3>    <p>这并不是一种独立的耦合方式,protocol可以结合上述各种耦合方式来进一步降低耦合,也是在复杂类关系设计中推荐的方式,比如我们可以定义这样一个protocol:</p>    <pre>  <code class="language-objectivec">@protocol LiquidContainer <NSObject>    - (id)provideWater;  - (id)provideCoffee;    @end    //Person.h  @interface Person : NSObject    - (void)drink:(id<LiquidContainer>)container;    @end</code></pre>    <p>上述的方式中,无论是Property持有还是parameter注入,都可以使用protocol来降低依赖,protocol的好处在于他只规定了方法的声明,并不限定具体是那个类来实现它,给后期的维护留下更大的空间和可能性。有关protocol的用处和重要性可以单独开一篇文章来讲。</p>    <h3>更复杂的场景</h3>    <p>以上是一些常见的类耦合方式,描述的两个类A,B之间的耦合方式。从上面的描述中,我们可以大致感知到两个类使用不同的方式所导致的耦合的 <strong>深浅</strong> ,这种耦合深浅度说白了就是: <strong>互相调用函数和访问状态的频次</strong> 。理解这种耦的深浅可以帮助我们大致去量化两个对象之间的耦合度,从而在更复杂的场景中去分析一个模块或者一种架构方式的耦合度。</p>    <p>在更复杂的场景中,比如A,B,C三个类之间也可以采用类似的方法去分析,A,B,C三者可以是如下关系:</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/1d9d7048cecdd723aa0467ec0eed0b20.png"></p>    <p>分析三个类或者更多类之间的耦合关系的时候,也是先拆解成若干个两个类分析,比如左边我们分析AB,BC,AC三组耦合,进而去感知ABC作为一个整体的耦合度。很显然,右边的方式看着比左边的好,因为只需要分析AB和BC。在我们选用设计模式重构代码的时候,也可以依照类似的方式来分析,从而选择耦合度最低,最贴合我们业务场景的模式。</p>    <p>我们的原则是:类与类之间调用的方法,依赖的状态要越少越好,在Objective C这门语言环境下,书写分类清晰,接口简洁的头文件非常重要。</p>    <h3>良性的耦合</h3>    <p>前面的分析重在尝试去量化和感知耦合的深浅,但并不是每一次方法调用都是有风险的,有些耦合可以称作是良性的。</p>    <p>如果将我们的代码进行高度抽象,所有的代码都可以被归为两类: <strong>Data和Action</strong> 。一个Class中的Property是Data,而Class中的函数则是Action,我之前写过的一篇关于函数式的文章中提到过,真正让我们代码变得危险的是状态的变化,即改变Data。如果一个函数是纯函数,既不依赖于外部状态,也不修改外部状态,那么这个函数无论被调用多少次都是安全的。如果两个类,比如上面举例的Person和Cup,二者互相调用的都是纯函数,那么二者之间的耦合可以看做是良性的,并不会导致程序的状态维护混乱,只是会让代码的重构变得困难,毕竟耦合的越深,重构改动的代码就越多。</p>    <p>所以我们在做设计的时候,应该尽可能使不同元素之间的耦合是良性的,这就涉及到状态的维护问题,先看下图中两种不同的设计方式:</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/a0afdb8c12815378c83ef85e712de474.png"></p>    <p>图中红色的圆圈代表每个类或者功能单位所持有的状态。依照图中上方的设计方式,每个单位各自处理自己的状态变化,这些状态之间还互相存在依赖的话,耦合越深,开发调试和重构就越难,代码就降级越厉害。如果按照图中下方的方式,将状态变化的部分全部都集中到一起处理,维护起来就轻松很多了,这也是为什么很多App都有model layer这一设计的原因,将App状态(各类model)的变化处理独立出来作为一个layer,上层(业务层)只是作为model layer的展现和交互的外壳。这种设计技巧,大可以应用于一个App架构的处理,小可以到一个小功能模块的设计。</p>    <h3>结束语</h3>    <p>上面总结了我们常用的一些耦合方式,目的在于分析不同代码的书写方式,对于我们最后耦合所产生的影响。最后值得一提的是,上面有些耦合方式并没有绝对的优劣之分,不同的业务场景下可能选择的方式也不同,比如有些场景确实需要持有Property,有些场景单例更合适,关键在于我们能明白不同方式对于我们代码后期维护所产生的影响,这篇文章有些地方可能比较抽象,其中很多都是个人感悟和总结,或有不妥之处,请阅读之后选择性的吸收,希望能对大家平常写代码处理耦合带来一些帮助。</p>    <p> </p>    <p>来自:http://www.jianshu.com/p/6c0c6e50420a</p>    <p> </p>