转自 大话设计模式：
1、本设计模式采用举例: 前台在门口观察老板是否回来，如果回来，则通知对应的同事，对应的同事进入工作状态。
part1:
一个观察者(前台), 一个股票观察者
进行测试:
观察发现: 前台和观察者之间都需要互相依赖，违反了开闭原则，part2进行解耦
part2: 对观察者进行抽象,因为可能不止有看股票的同事，还有玩游戏的同事，看NBA的同事
抽象观察者接口：有一个公共方法,更新
前台观察者注册的就不是具体的看股票的同事了，而是注册的抽象接口 Observer
测试:
结果发现：
观察者依然依赖了具体的前台，显然不符合逻辑。而且前台或者老板都有可能起到实际的通知动作，都有相同的行为。所以此处我们对通知者也进行抽象:
part3:
通知者老板和前台小妹都可以实现该接口：这里仅展示老板类(前台和老板类一致). 老板类有一个观察者的集合。当状态发生变化时, 就调用观察者的更新。
因为通知者进行了抽象，所以，在观察者这里也应该进行抽象，不依赖于具体，依赖于抽象。
测试:
因为玩游戏的同事和老板关系不好，老板想铲除他，估计不通知他，让他被抓个现行，让他辞职。所以移除了老板的通知列表，另外2个都是老板的心腹，回来之前就通知了。所以不会明面上被抓现行。
观察者模式定义:
定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己.
* subject每个主题(boss 和前台 都可以拥有任意个观察者(同事列表)，抽象主题提供一个接口可以增加和删除观察者)
* observer:抽象观察者，为所有的具体观察者定义一个接口，使得主题更新时通知到自己进行更新
结构图:
通知者抽象：
观察者抽象；
具体通知者：有一个注册的观察者列表, 有添加，删除，更新通知的方法。
具体观察者:
测试:
研究发现:
运用的动机:
将一个系统划分成一系列相互协作的类有一个很不好的副作用，因为需要相关对象间的一致性,我们并不希望为了维护一致性而使各个类之间紧密耦合，给维护、扩展、重用带来了不变。
使用的时机:
当一个对象的改变需要改变其他对象时，而且他不知道具体有多少对象有待改变，应该考虑使用观察者模式。当一个抽象模型有2个方面，其中一个方面依赖另外一个方面。可以用观察者模式将这两者封装在独立的对象中使他们独立的改变和重用。
总的来讲，观察者模式其实就是解除耦合，让耦合的双方都依赖于抽象，而不是依赖于具体，从而使各自的变化都不会 影响到另一边的变化。
