CTMediator：

优点：

1. 协定了Target-Action 方式，避免来了业务代码之间污染，组件之间解耦，易于维护
2. 使用了category声明接口， 相对于字典的方式传参更加在编译期就能够检查
3. category可以写对应的方法传不同的类型 b (字典)
4. 完全可以通过url的方式进行打开， 尤其是在web交互的时候，但是这样协定必须固定（否则需要转化）
   5)较为简单的轻量级

缺点：
1)需要给对应的模块添加target 和mediator分类， 代码太多
2)在 category 中仍然使用了字符串硬编码，内部使用字典传参 （这个目前好像没有太多好的处理方式）

3. 无法保证这个模块一定存在 。（有可能这个模块取掉或者修改了，但是它还是调用了，而没有发现这个错误且没有报错）
4. 调用链过长

iOS 模块化
CTMediator 解析参考
CTMediator 解析参考

PS： 小结

1、这个也是有代码入侵的，没有真正的黑盒
2、调用链过长，一个模块间的转场，在中间还插入了两个步骤
3、这个过程有方法属性——dictionary—— 设置属性 : 还不如直接使用属性了
4、invocation 完全无法保证这个模块的存在，（如果写这个模块，当然宗门自己保证能够存在） 这个不是什么大的问题。
5、如果我的一个module增加一个方法，就需要在增加的两个类里面增加对应的方法。 想想两个维度：增加类和增加方法，造成了2次方的增长暴涨。
6 、不建议使用这个库来进行处理

---

MGJRouter 使用openURL方式

---

1、 做到了解耦
2、其实就是一个路由的类，可以很方便的路由到配置的地方

缺点：

1: 还是中介者模式，这个增加了压力
2: 有关的路由的字段处理，字符串需要定义或者手写，比较麻烦

类似于项目中的XNRouter

XNRouter的结构

---

BeeHive

实现方式：基于接口的注册 + router的模块， + MVP = VIPER 架构
BeeHive 源码业务

1）代码划分 ，可以组件成为不同的模块
2）注册服务： 服务依赖于接口

缺点：
1）需要管理对应的类信息

PS：感觉用BeeHive还是可以减少代码的依赖的。