OC协议在解耦中的应用
2018-12-02 本文已影响66人
沙雕Wilson
OC协议在解耦中的应用

1,oc中利用协议代理解耦,
delegate是OC中常用传值模式,这是一种很好的设计模式。但是日常开发中仅限于传值,不能充分发挥它的价值。其本质是将接口与实现分离,下面是一种利用协议实现模块解耦的思路。
2,重构过程
1> 目标:① 项目移除任意业务模块,编译器不能报错,甚至运行期不报错。
② 不允许硬编码,不允许硬编码,不允许硬编码,,,
2> 思路。
利用协议声明接口,在需要调用接口的地方只引入协议,然后通过中间层获取该协议实现实例对象,调用接口。
3> 实现。
结构上,我们划分为 中间层,功能提供者,功能调用者。下面是实现:
#pragma mark - 声明协议
我们以加载网络图片为例,先声明协议接口。如下图

协议这个要归结到公用层,看个人吧,我思考了很久,最后把它抽出来放在公用层,这是个值得思考的问题。
#pragma mark - 中间层
中间层的作用:记录协议以及对应遵守协议的实现类,当调用者要获取该协议对应实现实例对象时,通过记录的类名生成实例对象返回给调用者。

中间层的结构十分简单,只有一个字典属性,是用来记录Protocol 与对应实现类名。上图。

中间层对于实现协议类的注册接口,传入一个协议,一个类名,中间层会将两个参数保存到字典中。上图。

对于获取delegate对象,调用者要传入一个协议。中间层根据记录的协议对应的类名,初始化一个对象返回给调用者,这个对象一定是遵守传入协议的。上图。
至此中间层的任务完成,不依赖任何功能模块。
#pragma mark - 功能提供者
功能提供者:引入要实现的协议,遵守协议并实现协议中的方法。在load中将自己实现的协议注册到中间层。

#pragma mark - 功能调用者
功能调用者:根据要调用的功能,引入对应的协议,通过中间层获取实现该协议的实例对象,并调用协议中的接口。

至此我们就可以随意更换webImage模块,甚至直接删掉这个模块也不会报错。
完结撒花。