目标－动作模式
Target-Action【哎可深---活动】 —— CTMediator【没底A特---传递者】
通过给组件包装一层wrapper来给外界提供服务，然后调用者通过依赖中间件来使用服务；其中，中间件是通过runtime来调用组件的服务，是真正意义上的解耦，也是该方案最核心的地方。具体实施过程是给组件封装一层target对象来对外提供服务，不会对原来组件造成入侵；然后，通过实现中间件的category来提供服务给调用者，这样使用者只需要依赖中间件，而组件则不需要依赖中间件。
https://www.jianshu.com/p/76132c91be47参考文献
VC之间的解耦
如果HomeViewController里有 N 个这样的 button 事件，每个点击后的跳转都是不同的页面，那么则HomeViewController里，需要导入 N 个这样的OneViewController.h;
如果HomeViewController是一个可以移植到其它项目的业务模块，在拖出首页HomeVC相关的业务代码时，难道还要把 'HomeViewController.m' 导入的 N 个其它XxxViewController.h都一块拖到新项目中么？
这点就是因为代码的耦合导致了首页HomeVC没法方便的移植。
说这样没有问题，是因为普通情况下，我们并没有移植HomeVC到其它项目的需求。
至于什么时候会有这样的问题，以及，这样的问题如果解决，在iOS组件化方案调研这篇中，已经做过简单的讨论，这篇主要是选取了我个人较偏向的Target-Action这套方案，简单讲一下实现方式。
解耦方法
创建一个 Target_News 类，在这个文件里，我们主要生成 NewsViewController 实例并为其进行一些必要的赋值。例如:
2.创建 CTMediator 的Category.
CTMediator+NewsActions.这个Category利用Runtime调用我们刚刚生成的Target_News。
由于利用了Runtime，导致我们完全不用#import刚刚生成的Target_News即可执行里面的方法，所以这一步，两个类是完全解耦的。也即是说，我们在完全解耦的情况下获取到了我们需要的NewsViewController。例如：
3.最终使用
由于在Target中，传递值得方式采用了去Model化得方式，导致我们在整个过程中也没有#import任何Model。所以，我们的每个类都与Model解耦。
