第19讲：Observer 观察者模式
2006.7.19 李建忠
发布-订阅模型
当我们账户的金额有任何的操作，如果我们订阅了服务，例如手机、Email等，那么我们都会得到通知。
动机（Motivation）
在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
意图（Intent）
定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新
——《设计模式》GoF
例说Observer应用
这样设计，如果还有其他设备需要通知，那么我们每次都需要频繁地修改BankAccount。
改进的设计
结构（Structure）
ConcreteSubject对应例子中的BankAccount，ConcreteObserver对应Emailer、Mobile等。
Observer模式的几个要点
使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者（面向对象中的改变不是指改代码，而是指扩展、子类化、实现接口），从而使二者之间的依赖关系达致松耦合。
目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。观察者自己决定是否需要订阅通知，目标对象对此一无所知。
在C#的event中，委托充当了抽象的Observer接口，而提供事件的对象充当了目标对象。委托是比抽象Observer接口更为松耦合的设计。
.NET框架中的Observer
AccountChange委托里面会遍历所有的委托链表里面的对象然后调用。
Emailer这里虽然并没有实现接口，但它其实隐含的约定了接口，它的方法名字可以不一定是Update，使得松耦合更加灵活。
委托的+号其实就是往委托链表里面Add通知的方法，委托事件把遍历的方法和添加删除方法都替我们做好了，但实现的原理还是和我们第一个例子一样。
Emailer和BankAccount之间没有强依赖，它们之间的依赖是靠第三方的委托依赖的，只要委托稳定，其它都会稳定。所以我们完全可以把委托看成一个接口，我们尽量要只依赖于委托，而不要让委托来依赖我们具体的类型。
2010.10.19
