解释：
定义了一种一对多的依赖关系，让多个观察者对象同事监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
结构图：
Subject类，主题通知者、抽象通知者。一般用一个抽象类或者一个接口实现。将所有对观察者对象的引用保存在一个聚集里，每一个主题都可以有任何数量的观察者。
Observer类，抽象观察者、更新接口。一般用一个抽象类或者一个接口实现。为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。
ConcreteSubject类，具体主题、具体通知者。通常用一个具体子类实现。将有关状态存入具体观察者对象。在具体主题的内部状态改变时，给所有登记过的观察者发出通知。
ConcreteObserver类，具体观察者。通常用一个具体子类实现。实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。可以保存一个指向具体主题对象的引用。
客户端代码：
针对的问题：
将一个系统分隔成一系列相互协作的类有一个很不好的副作用。那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合。这样会给维护、扩展、重用都带来不便。
优点：
观察者模式的关键对象：Subject和Observer。
一个Subject可以有任意数目的依赖它的Observer，一旦Subject的状态发生了变化，所有Observer都可以得到通知。
Subject发出通知时，并不需要知道谁是它的观察者（即，具体的观察者是谁？）
任何一个具体观察者不知道，不需要知道其他观察者的存在。
解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。依赖倒转原则的最佳体现。
使用环境：
当一个对象的改变需要同时改变其他对象的时候。且不知道具体有多少个对象有待改变。
当一个抽象模型有两个方面，其中一方面依赖于另一方面。观察者模式可以将这两者封装在独立的对象中，使他们各自独立地改变和复用。
使用建议：
什么时候使用抽象类？什么时候使用接口？
当具体观察者很相似，使用抽象类。这样可以共用一些代码。用接口只是方法上的实现，没什么太大的意义。
当具体观察者是风马牛不相及的类，但它们都需要根据统治者的通知来做出Update()的操作，那使用接口就可以实现。
缺点：
尽管用了依赖倒转原则，但是“抽象通知者”还是依赖“抽象观察者”，即没有了抽象观察者，通知的功能格式完不成的。
每个具体的观察者，”更新“的方法不一定同名。
优化：
使用事件委托。去掉父类“抽象观察者”，将”更新“方法名改为各自适合的方法名。
去除“抽象通知者”对“抽象观察者”的依赖。将抽象通知类的“增加”、“减少”以及“通知”时遍历抽象观察者都去除。转而让客户端使用委托来实现。解决耦合问题。
具体观察类,更新方法名不同。
抽象通知者，不依赖抽象观察，“增加”、“减少”、“通知”时遍历抽象观察者都没必要了。
声明一个委托
具体通知类，使用委托，实现不同方法名的“更新”。
客户端：实现不同方法名的“更新”，实现抽象通知类与抽象观察类的解绑，不用“增加”、“减少”，使用委托即可（一个委托可以搭载多个方法，所有方法被依次唤起）。
对比优化前：耦合更加严重些。
委托和事件：
就是一种引用方法的类型。一旦为委托分配了方法，委托将于该方法具有完全相同的行为。
委托方法的使用可以像其他任何方法一样，具有参数和返回值。
委托可以看做是对函数的抽象。是函数的‘类’，委托实例代表了一个具体的函数。delegate void EventHandler(),理解为声明了一个特殊的类；public event EventHandler Update(),理解为声明了一个时间委托方法叫“更新”；new EventHandler(tongshi1.CloseStockMarket),理解为一个委托的实例，将tongshi1.CloseStockMarket()委托给huhansan.Update()了。
一个委托可以搭载多个方法，所有方法被依次唤起。
更重要的是，委托对象所搭载的方法并不需要属于同一个类。
前提：对托所搭载的所有方法必须具有相同的原型和形式（即，拥有相同的参数列表和返回值类型）。