组件化之路的尝试

最新因为使用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