在全局数据同步系列文章中（一）（二）分别解决了model和view的全局同步，但是依然有一些问题，所以在这里给一个终极解决方案DDKeyPathChannel。
重新来说明下解决的问题
由于各种原因，目前有两个表示同一种类型的model。
@interface UserModel1 : NSObject
@property (strong, nonatomic) NSString *id;
@property (strong, nonatomic) NSString *name;
@property (assign, nonatomic) NSInteger age;
@end
@interface UserModel2 : NSObject
@property (strong, nonatomic) NSString *id;
@property (strong, nonatomic) NSString *nickName;
@property (assign, nonatomic) NSInteger age;
@end
现在需要其中一个属性修改了，或者第三方要求更新属性，如何更好的同步各个不同model之间的属性呢？
另一个问题，又如何把这个状态更新到UI上呢？
以前方案的问题
首先，来看看之前解决方案的几个问题。
- 所有基类都需要实现特定接口协议。这对于model来说会比较简单，但是对于UIView来说就比较麻烦。
- 使用上，实现上比较麻烦，需要注意的地方比较多，容易犯错误。
那么有没有不影响到原来的类的方式呢？
新思路
既然现有的类去实现这个协议比较麻烦，那么找一个第三方类，永久的实现这个接口，并且把消息转发到现有的类不就可以了吗。
我们都知道有一个类不继承于NSObject，功能就是代理，那么我们利用这个类来做消息转发。
接口如下
@interface DDKeyPathChannelBaseProxy : NSProxy <DDKeyPathChannelProtocol>
// 以下两个属性确定对象唯一性
@property (readonly, nonatomic) NSInteger channelType;
@property (readonly, nonatomic) NSString *channelId;
// 原本的对象
@property (weak, readonly, nonatomic) __kindof NSObject *target;
- (instancetype)initWithChannelType:(NSInteger)channelType channelId:(NSString *)channelId target:(NSObject *)target;
@end
// 这是一个通过keyPath+白名单的实现，可以通过mapper来映射真正的keyPath
@interface DDKeyPathChannelProxy : DDKeyPathChannelBaseProxy
@property (strong, nonatomic) NSArray<NSString *> *whiteList;
@property (strong, nonatomic) NSDictionary<NSString *, NSString *> *keyPathMapper; // messageKeyPath : realKeyPath
@property (strong, nonatomic) void(^valueWillChangeBlock)(__kindof NSObject *target, NSString *keyPath, __kindof id newValue);
@property (strong, nonatomic) void(^valueDidChangeBlock)(__kindof NSObject *target, NSString *keyPath, __kindof id newValue);
@end
// 这是一个block的实现，可以在同步的时候自定义转换与实现
@interface DDKeyPathBlockChannelProxy : DDKeyPathChannelBaseProxy
@property (strong, nonatomic) NSString *keyPath;
@property (strong, nonatomic) void(^valueChangedBlock)(__kindof NSObject *target, NSString *keyPath, __kindof id newValue);
@end
转发的核心在于消息的传递
// keyPath
- (void)setValue:(id)value forKey:(NSString *)key {
if (self.valueWillChangeBlock) self.valueWillChangeBlock(self.target, key, value);
[self.target setValue:value forKey:key];
if (self.valueDidChangeBlock) self.valueDidChangeBlock(self.target, key, value);
}
// block
- (void)setValue:(id)value forKey:(NSString *)key {
if ([key isEqualToString:self.keyPath]) {
if (self.valueChangedBlock) {
self.valueChangedBlock(self.target, key, value);
}
}
}
那么我们怎么去挂载这个代理对象呢，想到associate object，那么我们也很容易的控制自己的生命周期了。
这样，我们就不需要在现有类中实现方法来支持该功能了，而且这样也更好的封装屏蔽了这些比较特殊的功能。在实践中感觉这种方式的使用成本是最低的，大家也比较容易接受。
[self.user1 bindChannelType:ChannelTypeUser
channelId:self.user1.id];
[self.user2 addChannelProxyWithChannelType:ChannelTypeUser
channelId:self.user2.id
config:^(DDKeyPathChannelProxy *proxy) {
proxy.keyPathMapper = @{ @"name": @"nickName" };
}];
// 更新属性
[[DDKeyPathChannelManager sharedChannel] emitChannelType:ChannelTypeUser
channelId:@"1"
value:@"Tom"
forKeyPath:@"name"];
[[DDKeyPathChannelManager sharedChannel] emitChannelType:ChannelTypeUser
channelId:@"1"
value:@(30)
forKeyPath:@"age"];
UI层更新也可以通过这种方式，也可以选择使用KVO。
题外话
关于这个功能，很多人肯定想到了ReactiveX，关于这点，两者的确有部分相似的场景，但也有很多不同的地方。
关于更新UI这点，两者从效果上来看的确是一致的
object -> (signal, keyPath) -> UI
两者最大的不同在于，ReactiveX是monad的思想，是有输入输出，拥有明确的输入对象和观察对象，行为流程是从上游到下游。而本套方案是一个中间人模式，是一个星状结构，更像通知一点。
但是两者思想是类似的，ReactiveX是把各种行为封装成Signal，而我们是把消息使用keyPath来承载与转发。
如果想要使用ReactiveX来实现这个功能也不是不可以，创建一个全局的热型号(subject)，控制好回收(dispose)，也是可以实现该功能，但总感觉和RX的概念有点偏差了。
总结
从第一篇方案，到现在最终比较完美的一套方案，也是因为我们的需求在一步一步的变化，要求我们使用更好、更灵活的方案才能满足的结果。这个过程是一个不断思考不断反思的过程，从这个方案的演化中，我深有感悟，很多东西在创造出来的时候看似完美，但实际上还有很大的完善空间，同时别人的方案也会对自己的想法有很多的帮助。所以多了解别人的实现方案对自己的提升还是很有帮助的。
