设计模式-行为型-观察者模式（OBSERVER）

　　接下来咱们讨论一个最难被正确使用也是在框架设计中最容易被误用的设计模式，观察者模式。

　　”定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 全部依赖于它的对象都获得通知并被自动更新“

　　

　　上图是观察者模式的结构类图，乍一看会被这个设计模式的结构类图给吓个不轻。笔者想说结合这个结构的定义，一点一点跟着笔者一点一点梳理，你会很快茅塞顿开。

　　关于该设计模式的定义，咱们能够添加一些词让他更好被理解。”定义对象间的一种一（被观察者）对多（观察者）的依赖关系,当一个对象（被观察者）的状态发生改变时, 全部依赖于它的对象（观察者）都获得通知并被自动更新“。如此一来这个定义就好被理解了。全部观察者在由于被观察者的状态发生改变时收到通知。接下来咱们一步一步分析结构类图，类图中的Subject系列的类就是被观察者，而Observer系列的类就是观察者。咱们先看被观察者，被观察者维护了一个存储观察者的数据结构，这个数据结构多是链表、数组或是其余数据结构。被观察者经过Attach接口添加观察者，经过Dettach接口删除观察者。在被观察者对象的状态发生改变经过调用Subject父类的notify方法来通知到全部的已注册的Observer。通知Observer的方式是经过调用Observer的Update接口，这里须要注意的Update接口的调用方法，笔者注意到这里的类结构图只标注了一种方式。让咱们回顾一下策略模式（STRATEGY）,Context把有关算法的实现委托给了Strategy，调用Strategy时候有两种方式一种是推模式一种是拉模式。这里的类结构图是属于拉模式。固然也可使用推模式，既是经过往Update传入参数来通知Observer。两种方式都各有各得好处，具体请参见笔者对于这两种实现模式的总结。

　　这个设计模式的好处以及缺点体如今那些方面呢？

　　1. 第一个被观察者与观察者是彼此隔离的，被观察者不清楚观察者是谁（被观察者只有观察者的指针，而不知道观察者是属于哪一个子类），这样带来的好处是观察者极容易被拓展，后续程序员的工做只是新增长一个观察者的子类。因此这样的观察者与被观察者之间的耦合被固定在了相对固定的抽象层阶段。

　　2. 广播通讯，注意到整个通知方式是一对多的通知全部的观察者，因此观察者模式提供了相似于广播通讯的通知。注意到在拉模式的实现中，每一个观察者其实是拥有被观察者的引用的，因此每一个观察者都有触发这种广播通知的能力，正是这一类型的特性，有些广播的通知可能给系统带来很难被追踪的结果。