观察者模式
典型应用：客户端的MVC架构中M和V的关系，服务端数据更新存盘机制，游戏中任务，成就，预警的事件监听，都适合用观察者模式
模式描述：观察者模式主要用于处理”一“对”多“的关系，当“1”发生变化的时候，“多”需要分别发生变化，而且这个“多”的内容会进行动态增减，于是”多“就去”1“处订阅，当”1“发现自己变化了，就会遍历所有订阅他的“多”，并且对这些“多”一一告知（通过“多”订阅时候留下的对外接口），当“多”中的某个或者某些个体不需要再关心“1”的变化时，他们就会从“多”中脱离，离开这个“观察者系统”
现实案例：就像是订阅报纸，当一个客户想要订阅报纸，就会去邮局留下自己的住址和简要信息，报社和看报纸的人就是一对多的关系，报社是“1”，看报者是“多”，也就是观察者，当世界上发生大事件的时候，”报社“监听到了变化，用报纸作为媒介，发送到“看报者”留下的“地址”（代码里就是调用观察者留下的接口，发送改变的数据过去，接口就是地址），至于看报人收到报纸之后，会根据报纸上的信息做什么，报社就不用关心了，看报人也不需要关心报社是怎么获取到这些信息的，当某个看报人不想再接收报纸的时候，就会取消订阅，报社将这个人的地址从发报列表中清除即可
在地下组织里，安插入敌方的间谍每次会将消息发送给需要知道的人，间谍和接收者是单向联络，接收者不知道间谍是谁，怎么获取到这些信息的，他只需要根据信息的内容做出相应的安排即可，间谍也不用知道接收者是谁，他只要确保自己收到信息之后能准确地发给接收者即可，减少不必要的信息交流，避免暴露
In My Opinion：观察者模式主要是为了松耦合，将主体和观察者的关系只局限于观察，而杜绝其他一切不必要的关联，减少维护成本
观察者模式变种：并不是所有观察者都需要一切消息的，于是主体可以对观察者分类，就像报社会发布不同类型的报纸，面向的看报者也是不一样的，可以设计多个观察者池，不同的变化通知不同池中的观察者，同时可以设计一个消息过滤接口，过滤不必要的变化消息，防止观察者被频繁地无意义地通知
另外的观察者模式：通知中不附带具体消息，在数据发生变化后，将数据公开出来放在看板上，然后通知所有观察者：有新数据了！观察者根据自己的需求，从主体的看板上“拉”自己感兴趣的数据，这种设计不同于以往的主体“推”数据给观察者，变成了观察者收到通知自己“拉”数据，耦合度较之传统观察者模式高一些（违背了好莱坞原则），但是用起来比较灵活，减少了主体的复杂度
存疑：观察者模式中，主体为什么不能依赖通知观察者的顺序？