其他分享
首页 > 其他分享> > 组件化之路的尝试

组件化之路的尝试

作者:互联网

最新因为使用pod私有库来进行开发,将所有模块拆分成各个Private Pod,它的Podfile目录结构类似这样:

1
2
3
pod 'PrivateKit'
pod 'ModuleA'
pod 'ModuleB'

其中PrivateKit里面包含多个通用库,其中包含:RequestKit网络请求库(将所有请求看作一个对象),
ConfigurationKit(包含通用的样式以及配置信息等),第三方需要引用的库如:AFNetworking,SDWebImage等。

这样所有的业务模块可以进行拆分,业务模块可以选择依赖性于这个PrivateKit。这样的好处无疑是解耦模块业务之间的开发,将大的一个工程拆分成无数个小的子工程,适合多人协作的开发方式,每个开发人员无须深入理解多个业务模块之间的关系,只需要设计输出和输入的接口,这是比较理想的情况。

在这个道路上进行尝试,那其中首当要解决的问题就是去模块化的耦合,我们设想一下,如果ModuleB的初始化需要根据ModuleA用户选择和计算出的结果来进行判断,那就必须先ModuleA的一些Model传递给B,这样势必会进行耦合,所以优先考虑这个的解决方案。首先会想到的自然是加中间层,所有的一切都是通过这个中间件路由,一开始的构想是这样的:

又或者这样:

这样满足了我们之前的要求,解除了模块之间的直接关联,我们只增加了Mediator这样一个类去做,仔细观察上面这个图之后,会发现Mediator的作用显然被放大了,模块之间与Mediator的耦合越来越重,ModuleA与ModuleB的耦合是没有。如果方向上是正确的话,我们需要尝试去解决模块和Mediator之间的问题,尝试之后,觉得还是增加一个协议,来减轻他们之间的耦合关系,想象的是这样:

既然这样做的话,看起来是挺好,模块之间都遵循同一个协议,至于如何通过Mediator去打开Module,我们还缺少一层映射关系,目前从图中看不出有任何关系,所以就必须设置代理或者target,又或者回到之前的老路,在Mediator去注册,通过协议和open方法来执行。想想都不是一个好的方案,于是尝试另一种方式,在运行时,通过查找target就是具体的实例对象,来调用其中的方法完成模块之间的依赖性。将protocol通过引用一个新的类来代替,这个类叫做Behaviour,每个module中的每个page又或者是每个控制器都有一个扩展的行为来进行模块之间的功能,这个扩展行为我们定义为Behaviour类,这个是一个抽象类,让子类去说明自己是属于哪个类的扩展行为。
之后将它所有的扩展行为,通过Mediator的Catagetory去映射。这样我就没有必要一定要去遵守Mediator的Protocol。catagetory通过查看Behaviour的拥有者来映射这层关系。它似乎是这样

CHMediator GitHub地址

期间有一小插曲,可以通过performSelector来runtime机制,但不能处理多个参数,为了处理多个参数传递的映射,最后使用valist去接收参数,选择使用NSInvocation去执行和接收返回值,但在跳转Cotroller报出了很多野指针的错误,在僵尸模式调试下,发现竟然是

1
[ModuleAViewController release]: message sent to deallocated instance 0x7fbb67312410

这样的可能就是在控制器dealloc时候找不到了,其实是NSInvocation接收返回对象会被释放两次(由于ARC模式下NSInvocation并没有管理接收对象的原因),最后使用指针对象接收返回值,然后在用(__bridge id)转换成对象。

原文:大专栏  组件化之路的尝试


标签:尝试,Mediator,耦合,ModuleA,模块,化之路,组件,这样
来源: https://www.cnblogs.com/chinatrump/p/11615047.html