数据耦合的代码例子c语言,代码耦合的处理

耦合是每个程序员都必须面对的话题，也是容易被忽视的存在，怎么处理耦合关系到我们最后的代码质量。今天Peak君和大家聊聊耦合这个基本功话题，一起捋一捋iOS代码中处理耦合的种种方式及差异。

简化场景

耦合的话题可大可小，但原理都是相通的。为了方便讨论，我们先将场景进行抽象和简化，只讨论两个类之间的耦合。

假设我们有个类Person，需要喝水，根据职责划分，我们需要另一个类Cup来完成喝水的动作，代码如下：

//Person.h

@interface Person : NSObject

- (void)drink;

@end

//Cup.h

@interface Cup : NSObject

- (id)provideWater;

@end

很明显，Person和Cup之间要配合完成喝水的动作，是无论如何都会产生耦合的，我们来看看在Objective C下都有哪些耦合的方式，以及不同耦合方式对以后代码质量变化的影响。

方式一：.m引用

这种方式直接在.m文件中导入Cup.h，同时生成临时的Cup对象来调用Cup中的方法。代码如下：

#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

这应该是不少同学会选择的做法，要用到某个类的功能，就import该类，再调用方法，功能完成提交测试一气呵成。

这种方式初看起来没什么毛病，但有个弊端：Person与Cup的耦合被埋进了Person.m文件的方法实现中，而.m文件一般都是业务逻辑代码的重灾区，当Person.m的代码量膨胀之后，如果Person类交由另一位工程师来维护，那这位新接手的同学无法从Person.h中一眼看出Person类和哪些类之间有交互，即使在Person.m中看drink的声明也没有任何线索，要理清楚的话，只能把Person.m文件从头到尾读一遍，对团队效率的影响可想而知。

方式二：.h Property

既然直接在.m中引用会导致耦合不清晰，我们可以将耦合的部分放入Property中，代码如下：

//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

这样，我们只需要扫一眼Person.h就能明白，Person类对哪些类产生了依赖，比直接在.m中引用清晰多了。

不知道大家有没有好奇过，为什么在Objective C中会有.h文件的存在，为什么不像Javaÿ