观察者模式

简述

观察者模式（Observer Pattern），定义了对象间的一对多的依赖关系，让多个观察者对象同时监听某一个主题对象（被观察者）。当主题对象的状态发生更改时，会通知所有观察者，让它们能够自动更新。

背景

很多时候，在应用程序的一部分发生更改时，需要同时更新应用程序的其他部分。有一种方法是：让接收者反复检查发送者来进行更新，但是这种方法存在两个主要问题：

• 占用大量的 CPU 时间来检查新的状态
• 依赖于检测更新的时间间隔，可能不会立即获得更新

对于这个问题，有一个简单的解决方案 - 观察者模式。

模式结构

UML 结构图：

• 抽象主题（Subject）：跟踪所有观察者，并提供添加和删除观察者的接口。
• 抽象观察者（Observer）：为所有的具体观察者定义一个接口，在得到主题的通知时进行自我更新。
• 具体主题（ConcreteSubject）：将有关状态存入各 ConcreteObserver 对象。当具体主题的状态发生任何更改时，通知所有观察者。
• 具体观察者（ConcreteObserver）：实现 Observer 所要求的更新接口，以便使本身的状态与主题的状态相协调。

优缺点

优点：

• 观察者和被观察者是抽象耦合的
• 建立一套触发机制

缺点：

• 如果一个被观察者对象有很多的直接和间接的观察者，将所有的观察者都通知到会花费很多时间。
• 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
• 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

适用场景

• 有多个子类共有的方法，且逻辑相同。
• 重要的、复杂的方法，可以考虑作为模板方法。

案例分析

自从有了滴滴、快滴、Uber、神舟等各大打车平台，广大市民的出行便利了不少。但自从合并以后，补助少了，价格也上涨了很多，不 * XX 倍甚至打不到车。。。

滴滴：好，第一个月，价格上调至 12.5。。。 
过了不久，心里想着：纳尼，都垄断了，还不多涨涨，果断 15.0。。。

合并就是为了垄断，再无硝烟四起的价格战，整合成统一价格模式，用户也就没有了自由选择权。

在这里，滴滴相当于主题，司机相当于观察者。

http://blog.csdn.net/liang19890820/article/details/61925314