观察者模式，指的是定义一种对象间的一对多的关系，当一个对象的状态发生变化的时候，所有依赖于它的对象都将得到通知并更新自己。
现在要说的分歧在这里：
“推” 的方式是指，Subject 维护一份观察者的列表，每当有更新发生，Subject 会把更新消息主动推送到各个 Observer 去。
“拉” 的方式是指，各个 Observer 维护各自所关心的 Subject 列表，自行决定在合适的时间去 Subject 获取相应的更新数据。
“推” 的好处包括：
1、高效。如果没有更新发生，不会有任何更新消息推送的动作，即每次消息推送都发生在确确实实的更新事件之后，都是有意义的。
2、实时。事件发生后的第一时间即可触发通知操作。
3、可以由 Subject 确立通知的时间，可以避开一些繁忙时间。
4、可以表达出不同事件发生的先后顺序。
“拉” 的好处包括：
1、如果观察者众多，Subject 来维护订阅者的列表，可能困难，或者臃肿，把订阅关系解脱到 Observer 去完成。
2、Observer 可以不理会它不关心的变更事件，只需要去获取自己感兴趣的事件即可。
3、Observer 可以自行决定获取更新事件的时间。
4、拉的形式可以让 Subject 更好地控制各个 Observer 每次查询更新的访问权限。
—————————————————————————————————————-
2012-2-27 补充：
事实上 “推” 和 “拉” 可以比较的内容太多了，比如：
客户端通常是不稳定的，服务端是稳定的，如果消息由客户端主动发起去获取，它很容易找到服务端的地址，可以比较容易地做到权限控制（集中在服务端一处），服务端也可以比较容易地跟踪客户端的位置和状态，反之则不行；
互联网页面的访问就是一个最好的 “拉” 的模式的例子；
通常我们希望把压力分散到各个客户端上去，服务端只做最核心的事情，只提供内容，不管理分发列表；
……
还有一个 idea 是关于 “推” 和 “拉” 结合的形式，例如，服务端只负责通知某一些数据已经准备好，至于是否需要获取和什么时候客户端来获取这些数据，完全由客户端自行确定。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
×Scan to share with WeChat
