说是读后感,根本算不上,当记个笔记,划个重点吧。

Reference

Demo

iOS 对象交互模式

  1. 直接 Property 传值
  2. Delegate
  3. KVO
  4. Block
  5. Protocol
  6. 多态
  7. Target-Action
  8. Responder Chain

借助 Responder Chain 实现一个自己的事件传递链。
局限:仅用于 Responder Chain 上的 UIResponder 对象上。

实现基于 Responder Chain 的对象交互方式

仅需要一个 UIResponder Category 就可以实现。

UIResponder+Router.h

1
2
3
4
5
6
7
#import <UIKit/UIKit.h>

@interface UIResponder (Router)

- (void)routerEventWithName:(NSString *)eventName userInfo:(NSDictionary *)userInfo;

@end

UIResponder+Router.h.m

1
2
3
4
5
6
7
8
9
10
#import "UIResponder+Router.h"

@implementation UIResponder (Router)

- (void)routerEventWithName:(NSString *)eventName userInfo:(NSDictionary *)userInfo
{
[[self nextResponder] routerEventWithName:eventName userInfo:userInfo];
}

@end

分析基于 Responder Chain 的对象交互方式

Responder Chain 可以无视命名域的存在
如果采用传统 Delegate 层层传递方式,由于 Delegate 需要 Protocol 声明,因此无法做到命名域隔离。

缺点

  1. 只能对存在于 Responder Chain 上的 UIResponder 对象起作用。

优点

  1. 以前靠 Delegate 层层传递的方案,可以改为这种基于 Responder Chain 的方式来传递,复杂 UI 层级中,避免无谓的 Delegate 声明。
  2. 由于众多自定义事件都通过这种方式做了传递,就使得事件处理逻辑得到归拢,在这个方法下断点就能够管理所有的事件处理。
  3. 使用 Strategy 模式优化后,C 和 V 的事件响应逻辑得到了很好的管理,响应逻辑不会零散到各处。
  4. 此基础上使用 Decorator 模式,更加有序地收集、归拢数据,降低工程维护成本。

由于事件被独立出来,可以极大减轻 MVC 中 C 的负担。
实际工程,可以创建 EventProxy 对象,专门用于处理 Responder Chain 上传递的事件。

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