开端
这天在对象村，林家找来了城东城西城北城南的媒婆们，拜托她们给今天弱冠的林一找对象。并把嫁入林家的优势给各个媒婆都说了一遍，让她们背熟好帮着林家说亲。
媒婆这个行业呀，虽说手里有着自己范围内的及笄姑娘的信息，看着很吃香的样子。但是这些姑娘的喜欢和习性几日一变，每天除了要跟这些姑娘背一遍各家公子哥的提亲要求还要返回去给那些公子哥说人家姑娘娘家的想法。这讨价还价的活来来回回也是把媒婆累的够呛，被鸽的情况也高，最终配对率还低.....
总结来说，存在的问题有：
- 信息不对称，信息更新慢
- 新增或者减少一个待通知的人，成本都很高
创新
饱读诗书的林一，悄悄找来媒婆，跟她说一个“一本万利”的想法。
- 求亲者只能等通知行动，所以叫做观察者（Observer）。
- 媒婆由于管理着各家大闺女的信息，肩负一有风吹草动就要通知求亲者的责任，所以就叫主题（Subject）。
- 让来排队等相亲的人都在对应的 Subject 注册登记，然后 Subject 用一个名册（List）记录这些人的名字联系方式。（registerObserver）
- 当 Subject 这边有新的消息的时候，就照着名称上的名字，用飞鸽传书通知他们就行。（notifyObserver）
- 当他们成功脱单（或者决定孤独终老）的时候，就通知 Subject 一声，从名册上删了他们的名字就可以。（removeObserver）
- 而求亲者只需要按照 Observer 的规范，对外提供一个 update 的接口，在里面安排上你的撩妹套路，让他们在通知你的时候无需过多的解释直接调用这个接口，你就可以开始你的表演。
如图：
使用模式前
- 媒婆要背下那些相亲条件，记住他们各种喜欢什么类型的女孩子
- 每次求亲者的变动对媒婆来说都是一个麻烦
使用模式后
- 媒婆和待求亲者都不需要提前知道这些相亲的人是高矮胖瘦，贫穷还是富有，他们统统只是名册上的一个名字而已。想pass谁就pass谁，在名册上划掉就行。后来的只要注册就在名册上加个名字【旁白：唯一的依赖是一个实现了Observer接口的集合，可以随时新增或删除观察者】
- 媒婆再也不用知道这些人说了些什么，干了什么，爱干嘛干嘛，成了记得包红包就行。【旁白：只知道观察者实现了Observer接口，无需知道具体的观察者类】
- 想要相亲的人只需要都注册登记按流程走就可以了，只要登记了，基本都有机会在姑娘家面前露个脸。【旁白：通知所有实现了接口的对象，新的观察者只需要实现同个接口并注册】
应用场景的背景
- 主题管理着数据（媒婆掌握着你的相亲对象）
- 主题数据改变需要通知观察者（媒婆有新的消息马上通知单身的你们不会漏）
- 主题的观察者会收到更新（单身的你们需要知道一手消息，尽快脱单）
应用场景的特点
- 一对多的依赖
- 一个对象状态的改变，其依赖者会得到通知
- 不让多个对象控制同一数据
- 主题可以主动推数据，观察者也可以自行拉数据
知识点
观察者模式在对象之间定义一对多的依赖，这样端给一个对象改变状态，依赖他的对象会收到通知并自动更新
松耦合的设计会使系统更有弹性
应用该模式的例子
mq的生产者和消费者
