利用响应链传递自定义UI事件

前言

老早之前看到过一篇文章『路由响应链方法进行传值』，讲到如何通过响应链机制来解决多层嵌套自定义View时，重复而又累赘的事件传递问题。当时看完文章有感而发，自己也想出一个解决办法来。只不过苦于这大半年公司项目繁忙，而且我这个方法并不是那么实用，所以一直没有分享出来。最近有闲暇时间了，拿出来跟大家分享一下。

背景

众所周知，自定义一个View时，如果内部有按钮点击事件或者其他手势事件，需要将这些事件“告知”给上层的View或者Controller的时候，常规的做法是借助于delegate（自定义协议）或者block。这本身是再正常不过，没有任何问题。但是，一旦嵌套了多个层级的自定义View的时候，就会发现这其中会有很多重复的工作——层与层之间需要重复定义delegate或者block，而这些delegate或者block的目的又是一样的，仅仅是为了把事件“告知”给上层控件。举个例子：

有点模糊，大家凑合着看吧==!

在这里，MyView监听Button的点击事件，MyView通过delegate或者block将事件“告知”给MyCell，MyCell再通过类似的delegate或者block“告知”给Controller。尽管我们可以只定义一个可以共用的delegate协议，但是在MyCell和MyView还是要写两遍delegate属性的声明，以及对delegate的调用。
要是再多嵌套一层自定义View，重复的工作量可想而知。这里给大家分享一个非常规的方法。

分析

首先，分析一下，我们最终目的是希望省去delegate或者block重复的声明和调用，而将内部的一个事件传达给上层控件（不一定是直属上层）。联想一下，这和系统传递用户事件的响应链机制不是类似的吗。响应链机制中重要的一个特性是，只要中间在某一层该事件有被响应了，那么中断事件的传递，不然则继续向上层传递。这正是我们想要的。这其中有一个至关重要的角色——nextResponder，我们当然也会在这个属性上做文章。然后就是，我们怎么做到响应了就中断，不响应就继续向上传递呢。其实也很简单，所谓“响应”，就是在该控件里实现了某个方法，“不响应”就是没有实现该方法，就再传给上层去判断。说穿了，其实就是OC的另一个机制——消息转发。我们通过“消息转发”，把当前的事件转发给其他对象，即，nextResponder。

实践

有了思路和方向，接下来就好办了，实现起来很简单。直接上代码：

UIResponder+Forward.h

@interface UIResponder (Forward)

@end

UIResponder+Forward.m

@implementation UIResponder (Forward)

- (id)forwardingTargetForSelector:(SEL)aSelector {
    if ([self respondsToSelector:aSelector]) {
        return self;
    } else {
        return self.nextResponder;
    }
}

@end

代码逻辑就不解释，应该很好理解。这里要解释一下的是，为什么使用分类（Category）。使用分类（Category）的目的是，通过重写forwardingTargetForSelector:方法，来覆盖原类中默认的方法。这样一来，不需要其他代码，仅仅是创建这样的一个分类，即可在项目中生效（这也是一个坑点，最后总结里会讲到）。我们再来看下，项目里该怎么运用，还是以开头的例子为例。

假设给按钮添加了如下的点击事件：

[button addTarget:self action:@selector(buttonAction:) forControlEvents:UIControlEventTouchUpInside];

然后，在MyView中什么都不做，也就是说不去实现buttonAction:方法（这里会有黄色警告，暂时不去管它，有兴趣的可以思考下如何消除这个警告）。MyCell中也是什么都不做，最后在Controller中实现buttonAction:的方法。这样，MyView中因为没有实现该方法，会触发转发机制。而转发机制中的forwardingTargetForSelector:方法已被我们覆盖掉，这样就会转发给nextResponder，在这个例子就是MyCell。以此类推，最终转发给了Controller，而Controller实现了该方法，“响应链”就中断了。大家可以自行实验一下效果。

写在最后

不管读者们对此怎么想，开头部分就说过了，这个方法其实是不实用的。为什么呢，主要是因为使用了分类（Category），里面覆盖了原类的方法，这在多人合作的项目中是一个大忌。因为这样的一个分类（Category），仅仅是它的存在就改变了一些默认行为，这样会使得项目中其他开发者在遇到问题时，完全摸不着头脑，增加了项目维护难度。其次，UI上的一些交互逻辑本就应该是清晰明了的，除去分类（Category）的影响不说，本身这种转发的机制就大大降低了代码的可读性。可以说是装逼指数远大于实用指数，所以并不推荐大家使用。之所以分享出来，也算是抛砖引玉吧，希望能开阔一下大家平时写代码的思路。

谢谢阅读！