写在前面
第一次写博文，旨在分享在学习的过程中发现并解决问题的经验和一些看法。最近在学习runtime的相关知识，看到关联对象这一点时，觉得挺有意思的。PS：这篇文章的点子来自《Effective Objective-C 2.0》。
关于UIAlertView
在iOS8以前，我们需要弹出一个AlertView并且自定义响应的事件时候，都需要遵守<UIAlertViewDelegate>,然后在回调方法中根据索引去处理点击之后的逻辑。
久而久之，真心觉得这是一个非常繁琐而无趣的过程。并且，如果在一个页面中，有多个alertView需要弹出的时候，那么你还需要对每一个判断是哪个alertView。那么，有没有什么好的办法可以简化这些繁琐的过程呢？最好的方式就是传入一个block作为事件的回调。iOS8已经有了UIAlertController，并且可以通过给其添加UIAlertAction的方式来指定每个选项点击事件。action也是采取了block的方式。
+ (instancetype)actionWithTitle:(NSString *)title style:(UIAlertActionStyle)style handler:(void (^)(UIAlertAction *action))handler;
我们也可以通过给UIView添加分类（Category）的方式来达到类似的效果。
UIVIew+MyAlertView
添加两个方法（为了方便，可以自己选择用哪种），并且定义响应的block。
第一个方法中，为什么要把action放在那么尴尬的位置？因为alertView的变参(OtherButtonTitles,...)只能作为方法的最后一个参数。
我们来看两个方法的实现。
这里有个小问题，就是我们自定义的方法，传进来的other这个可变的参数，在我们创建一个alertView的时候，只能取到第一个参数。什么意思呢？比如你在调用的时候传入@"A",@"B",nil,如果你直接使用了这个参数，那么你的alertView只能显示"A"这个按钮。具体的原因我找了好久也没有找到（如果你知道，请告诉我，thank you）。所以我采用了遍历这个变参，通过alertView自身的addButtonWithTitle:方法来添加按钮。
有关可变参数的知识，可以参考wikipedia中的解释
接下来的就是runtime中的关联对象（associative）了。我们要在alertView的代理方法中，执行block，所以我们需要把block保存起来（虽然可以用全局变量的来做）。但是我们知道，oc的分类（也叫类别）是无法扩展属性的（I don't konw why）。那么我们则可用在运行时给他关联上。
objc_setAssociatedObject(<#id object#>, <#const void *key#>, <#id value#>, <#objc_AssociationPolicy policy#>)
-- object是关联到谁身上（self）。
-- void *key就是一个键，用来找到关联的对象，和NSDictionary的key是一样的，需要传入一个void *指针。
-- value是要关联的对象（这里是block）。
-- 最后一个是对这个对象（block）的内存管理方针。取值和oc中的属性修饰符是像对应的，比如 OBJC_ASSOCIATION_COPY=> copy。
与之相对应方法objc_getAssociatedObject(id object,void *key)则就是从字典中取值一般。
方法二除了更简洁，总的来说于一无差。
我们在使用的时候呢，则会比较方便了，不必写代理方法、不必判断，而且代码逻辑不必分散。
细心的你可能已经注意到了这种方式的隐患，就是block的保留循环（retain cycle）问题。
self通过关联对象保留了action块，如果在在action块中引用了self的成员变量（假定为对象），比如说对这个对象赋值，那么action这个block则会通过这个成员变量间接又引用self，那么保留循环就产生了。
我们这个比较好解决，因为我们在点击完了alertView之后，就不必在持有这个action块了，所以在callBack执行之后（见方法二图），就把关联的对象给remove掉了。为什么不用objc_removeAssociatedObjects？苹果说这个方法的目的是为了让被关联者，回到最初的状态。如果你仅仅需要remove某个关联的对象，用set方法设置成nil就行了。
总的来说，关联对象还是挺有意思的。扩展开来，比如说你要给任何的视图添加tap手势、滑动手势等，都可以使用这种方式。不过需要注意的就是保留循环的问题。
欢迎各位指正纠错，与君共勉。
