<a href="http://www.cnblogs.com/wolf-sun/p/3468100.html">[Head First设计模式]山西面馆中的设计模式——装饰者模式</a>
不知不自觉又将设计模式融入生活了，吃个饭也不得安生，也发现生活中的很多场景，都可以用设计模式来模拟。原来设计模式就在我身边。
为什么观察者模式会出现呢？ 为了建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应做出反应。在此，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间没有相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展，这就是为什么需要观察者模式。
观察者模式（Observer Pattern）：定义了对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式又被称为发布-订阅（Publish/Subscribe）模式，模型-视图（Model/View）模式，源-监听器（Source/Listener）模式，或从属者（Dependents）模式。观察者模式是一种对象行为型的模式。
当两个对象是松耦合的，它们之间能够交互，但是相互了解的很少。
观察者模式提供了主题和观察者之间的松耦合设计。因为主题只知道观察者实现了某个接口（即Observer接口）。主题不需要知道具体观察者是谁，做了些什么或其它任何细节。要增加新的观察者或删除观察者，主题不会受到任何影响，不必修改主题代码。
可以独立地复用主题和观察者，他们之间互不影响，即是松耦合。
设计原则：在交互的对象之间争取松耦合设计 由于松耦合设计使得对象间的依赖最小化，所以，我们能够创建柔性的oo系统，应对变化的情况，因为对象间的依赖降到了最低。
书中的气象站例子：
代码实现：
在WeatherData中实现主题接口
建立布告板
测试代码
结果：
场景：山西面馆中，我点餐，服务员传话给厨师，厨师应答，厨师做饭。
分析：在这个场景中，我：被观察者，服务员，厨师：观察者。
我：“一份西红柿鸡蛋汤面”
一系列动作
服务员：1.向厨师传话“一份西红柿鸡蛋汤面”
厨师：1.收到，2.开始做。
在.NET中，C#使用委托以及事件，可以很好的实现观察者模式。委托相当于“订阅清单”的角色，当目标中关联了该委托的事件被触发时，则委托将自动按序执行观察者注册于委托中的方法。
代码实现：
基类的实现
观察者实现
被观察者
测试：
当一个对象的数据更新时需要通知其他对象，但这个对象又不希望和被通知的那些对象形成紧耦合。
当一个对象的数据更新时，这个对象需要让其他对象也各自更新自己的数据，但这个对象不知道具体有多少对象需要更新数据
观察者模式与备忘录模式的关系
观察者模式使用了备忘录模式（Memento Pattern）,暂时将观察者对象存储在被观察者对象里面
观察者模式与MVC模式的关系
观察者模式可以用来实现MVC模式。观察者模式中的主题便是MVC模式中的模型加控制器，而观察者便是视图
一般情况下，MVC是观察者模式、组合模式、策略模式等设计模式的组合。
观察者模式的有点
1，具体主题和具体观察者是松耦合关系。
由于主题（Subject）接口仅仅依赖于观察者（Observer）接口，因此具体主题只是知道它的观察者是实现观察者（Observer）接口的某个类的实例，但不需要知道具体是哪个类。同样，由于观察者仅仅依赖于主题（Subject）接口，因此具体观察者只是知道它依赖的主题是实现主题（subject）接口的某个类的实例，但不需要知道具体是哪个类。
2，观察者模式满足“开-闭原则”。
主题（Subject）接口仅仅依赖于观察者（Observer）接口，这样，我们就可以让创建具体主题的类也仅仅是依赖于观察者（Observer）接口，因此如果增加新的实现观察者（Observer）接口的类，不必修改创建具体主题的类的代码。同样，创建具体观察者的类仅仅依赖于主题（Observer）接口，如果增加新的实现主题（Subject）接口的类，也不必修改创建具体观察者类的代码。
观察者模式的缺点
如果一个被观察者对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
如果在被观察者之间有循环依赖的话，给观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察者模式时要特别注意这一点。
虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制是观察者知道所观察的对象是怎么发生变化的
参考书
Head First 设计模式