你要知道的KVC、KVO、Delegate、Notification都在这里
转载请注明出处 //www.greatytc.com/p/9215251693f0
本系列文章主要通过讲解KVC、KVO、Delegate、Notification的使用方法，来探讨KVO、Delegate、Notification的区别以及相关使用场景，本系列文章将分一下几篇文章进行讲解，读者可按需查阅。
- KVC 使用方法详解及底层实现
- KVO 正确使用姿势进阶及底层实现
- Protocol与Delegate 使用方法详解
- NSNotificationCenter 通知使用方法详解
- KVO、Delegate、Notification 区别及相关使用场景
KVO、Delegate、Notification 区别及相关使用场景
经过前面四篇文章的学习我们已经可以熟练使用KVO、Delegate和Notification了，但三者又有什么区别呢？
在实际开发中需要在View和Controller之间进行通信，也需要跨Controller进行通信，上述三种方式都是为了通信而生，这三种方法都能够减少耦合，使得View或是Controller能够自包含，尽量不受其他对象的影响，这样就能够实现尽可能的复用。
针对某一需求往往有不止一种实现方式，当然上述三种方法也都可以互相替换，所以我认为没有百分百正确的使用方法或是百分百错误的使用方法，只有合适和不合适的方法，我们尽量挑选最适合应用程序开发的方式来满足我们的需求，接下来的内容可能并不完全正确，仅仅是我的个人理解，如果错误还请不吝赐教。
KVO
KVO在mac开发中使用的非常频繁，KVO提供了一个对象监听另一个对象属性值变化的方法，KVO适合多对一的监听，多个对象可以监听同一个对象属性值的变化，我们在开发中常用于监听Model属性值的变化从而动态的更新视图，它提供了一种模型属性值一旦修改视图可以立即按需求修改的功能，其优点有:
- 创建监听器的实现简单，只需要注册后实现回调函数即可
- 能够实现多对一的监听，多个对象可同时监听同一个对象属性值的变化
- KVO提供了监听新值以及旧值的方法，可以获取到修改前的值
- 支持keyPath来监听嵌套属性值
- 支持context区分监听器
但是经过前面KVO文章的讲解，我们也发现了其不少缺点:
- 注册监听器和删除监听器必须成套出现
- 重复删除监听器会发生异常
- 监听器对象销毁前未删除监听器可能发生野指针异常
- 继承类的KVO处理较复杂
- keyPath为字符串类型不能提供编译器检查
- 监听的属性值源码的名称发生变化需要修改代码
Delegate
在学习iOS开发时，我们最常用的应该就是委托模式了，UITableView、UICollectionView等等，委托模式提供了两种实现方式，一种是事件的代理，一种是数据源的代理，我们可以通知委托对象针对相关事件进行响应，也可以从委托对象获取想要的数据，委托模式基于协议protocol实现，提供了一种规范化的实现方式，并且delegate是一种一对一的实现方式，其优点有:
- 基于协议实现，提供了规范化的实现方法
- 在编译期就能够检查是否实现了代理必须实现的方法
- 提供事件响应的代理模式
- 提供数据源的代理模式
- 即时没有委托对象也不会产生异常
其缺点有:
- 规范化带来了实现上的复杂，必须遵守协议并实现所有方法
- 只能实现一对一的通信，如果多个对象都委托同一代理，为了区分不同的被委托对象，造成代码的复杂化
NSNotificationCenter
NSNotificationCenter通知中心提供了一种多对一的通信方式，与KVO相同，多个监听器对象可以同时监听同一通知，能够提供低耦合的实现方式，监听器对象可以接收到通知的信息，但发送通知的对象实现了隐藏，无法得知具体的发送对象，iOS中很多系统控件都会发送相关通知，最常见的如键盘，包括应用程序的状态等，其优点有:
- 创建通知的监听器简单，只需注册后实现监听放法即可
- 能够实现多对一的监听
- 通过NSNotification的userInfo能够传递通知的信息
- iOS9以后不需要手动删除监听器对象也不会产生异常
其缺点有:
- 通知名称使用字符串类型，在编译器无法检查
- 参数传递使用userInfo字典类型，参数获取需要规范定义
- 不能获取发送通知对象的状态信息
总结
从上面的优缺点分析来看，三种方法都有各自的优缺点，因此，没有正确与否，只有适不适合我们的需求，我在开发中使用较多的是delegate和KVO，但KVO的使用过多后就会发现有些滥用，在某些情况下NSNotificationCenter更加适合，并且KVO在使用时必须非常小心的注册和删除监听器。
备注
由于作者水平有限，难免出现纰漏，如有问题还请不吝赐教。
