这种对象交互方式的缺点显而易见，它只能对存在于Reponder Chain上的UIResponder对象起作用。

优点倒是也有蛮多：

• 以前靠delegate层层传递的方案，可以改为这种基于Responder Chain的方式来传递。在复杂UI层级的页面中，这种方式可以避免无谓的delegate声明。

• 由于众多自定义事件都通过这种方式做了传递，就使得事件处理的逻辑得到归拢。在这个方法里面下断点就能够管理所有的事件处理。

• 使用Strategy模式优化之后，UIViewController/UIView的事件响应逻辑得到了很好的管理，响应逻辑不会零散到各处地方。

• 在此基础上使用Decorator模式，能够更加有序地收集、归拢数据，降低了工程的维护成本。

基于ResponderChain的对象交互方式的适用场景首先要求事件的产生和处理的对象都必须在Responder Chain上，这一点前面已经说过，我就不再赘述了。

它的适用场景还有一个值得说的地方，就是它可以无视命名域的存在。如果采用传统的delegate层层传递的方式，由于delegate需要protocol的声明，因此就无法做到命名域隔离。但如果走Responder Chain，即使是另一个UI组件产生了事件，这个事件就可以被传递到其他组件的UI上。

举个例子：XXXViewController属于A组件，这个UIViewController的view上添加了B组件的某个YYView。那么YYView的事件在通过Responder Chain被XXXViewController处理的时候，就可以不必依赖B组件的YYView了。当然，如果事件本身传递了只有B组件才有的对象，无视命名域这个优点就没有了，不过这种场景在实际业务中其实也不多。

最后要说的是，由于事件被独立了出来，它可以极大减轻MVC中C的负担。在我们实际工程使用中，我创建了EventProxy对象，专门用于处理Responder Chain上传递的事件：

#pragma mark - event response- (void)routerEventWithName:(NSString *)eventName userInfo:(NSDictionary *)userInfo{
    [self.eventProxy handleEvent:eventName userInfo:userInfo];}

在这种场景下就做到了UI展示与事件处理的分离，事件处理的代码就可以归拢到另外一个对象中去了，使得C的代码量得以减少。

或许可以算是一种新的架构模式：MVCE（Modle View Controller Event）？其实名字、模式什么的都已经不重要了，毕竟所有的架构模式都是脱胎于MVC的，作不同程度的拆解罢了。

总结

这个交互方式是我的同事小龙告诉我的，我觉得很有意思。在实际工程中应用起来也十分得心应手，尤其是UI复杂且事件数量极多的场景，拿它来处理多事件逻辑是十分合适的。

我们在商品详情页中使用了这种对象交互方式：商品详情页有各种cell，每个cell上面又有各种button事件，每个Cell也有各自的子View，子View中也有button事件需要传递，而cell本身也需要相应点击事件。在这种复杂且多层级UI事件场景下，如果用delegate的方式层层传递，代码确实不如用Responder Chain的事件交互方式容易维护。用block的话，事件处理逻辑就会被分散在各个对象生成的地方。用Notification则更加不合适了，毕竟它并不属于一对多的逻辑，如若其他业务工程师在其它地方也监听了这个Notification，事件处理逻辑就会变得极为难以管理。

所以我写了这篇文章介绍了一下这个方式，希望能够在大家日常开发遇到类似场景时提供一点儿帮助。