iOS KVO观察者模式的深入理解

谈到KVO我们就会联想到『观察者模式』，其实KVO就是在oc中实现观察者模式。那下面就对观察者做一个简单介绍：

观察者模式（有时又被称为发布（publish）-订阅（Subscribe）模式、模型-视图（View）模式、源-收听者(Listener)模式或从属者模式）是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实现事件处理系统。

基本简介：

观察者模式（Observer）完美的将观察者和被观察的对象分离开。举个例子，用户界面可以作为一个观察者，业务数据是被观察者，用户界面观察业务数据的变化，发现数据变化后，就显示在界面上。面向对象设计的一个原则是：系统中的每个类将重点放在某一个功能上，而不是其他方面。一个对象只做一件事情，并且将他做好。观察者模式在模块之间划定了清晰的界限，提高了应用程序的可维护性和重用性。

观察者设计模式定义了对象间的一种一对多的依赖关系，以便一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动刷新。

实现方式：

观察者模式有很多实现方式，从根本上说，该模式必须包含两个角色：观察者和被观察对象。在刚才的例子中，业务数据是被观察对象，用户界面是观察者。观察者和被观察者之间存在“观察”的逻辑关联，当被观察者发生改变的时候，观察者就会观察到这样的变化，并且做出相应的响应。如果在用户界面、业务数据之间使用这样的观察过程，可以确保界面和数据之间划清界限，假定应用程序的需求发生变化，需要修改界面的表现，只需要重新构建一个用户界面，业务数据不需要发生变化。

“观察”：

实现观察者模式的时候要注意，观察者和被观察对象之间的互动关系不能体现成类之间的直接调用，否则就将使观察者和被观察对象之间紧密的耦合起来，从根本上违反面向对象的设计的原则。无论是观察者“观察”观察对象，还是被观察者将自己的改变“通知”观察者，都不应该直接调用。

过程：

实现观察者模式有很多形式，比较直观的一种是使用一种“注册——通知——撤销注册”的形式。下面的三个图详细的描述了这样一种过程：

观察者

（Observer）将自己注册到被观察对象（Subject）中，被观察对象将观察者存放在一个容器（Container）里。（这样做是为了后面的调用）

被观察

被观察对象发生了某种变化（如图中的SomeChange），从容器中得到所有注册过的观察者，将变化通知观察者。（这里就可以验证上面的为什么会把观察者放入被观察中，为了就是能调用外面的方法）

撤销观察

观察者告诉被观察者要撤销观察，被观察者从容器中将观察者去除。

观察者将自己注册到被观察者的容器中时，被观察者不应该过问观察者的具体类型，而是应该使用观察者的接口。这样的优点是：假定程序中还有别的观察者，那么只要这个观察者也是相同的接口实现即可。一个被观察者可以对应多个观察者，当被观察者发生变化的时候，他可以将消息一一通知给所有的观察者。基于接口，而不是具体的实现——这一点为程序提供了更大的灵活性。

这里可通过一句话可以理解，被观察者是专门用来监听是否会发生变化的，观察者是用来接受到状态的改变做具体的事情，这种模式可以实现一对多而我不产生多余的对象。

下面就是oc中的代码做证实：

下面是一个注册观察者和被观察着，这里具体在runtime做的事情是这样的。首先他会创一个新类但是会继承原来的类，类名为NSKVONotifying_lab而且会在这个过程中会就观察者对象储存在这个类中，但这个类中有任何的风吹草动的观察者就会调用外面的监听方法

触发被观察者：

KVO就是一个在oc中实现的观察者模式实现思路也是相同的，只是具体的是东西不一样而已。这种模式可以在我们的代码中可以借鉴的使用，下一步我将具体的写一个demo来讲讲观察者模式在我们代码中的应用。