《设计模式Design Pattern》读书笔记之十七
Observer模式
结构
目的
在一个一对多(one-to-many)的关系中，当一个对象(one)的状态被更新的时候，它的所有的相关对象(many)都会被得到通知。
讨论
1， 可能会带来很大的状态更新成本，subject的一个很小的状态更新都可能使得大量的observer进行相应的更新。更为严重的是，如果subject不提供是什么状态被更新了这样的信息，observer可能会被迫辛苦地去找出来什么东西被更新了。
2， 如果一个observer可能对应多个subject，在Update接口可以提供一个参数，传入subject的地址，这样使得observer知道是subject进行了更新。
3， 对于什么时候触发notify，有两个选择：
A． 每当subject的state被更新的时候，自动触发notify。缺点是，可能会带来不断的更新的开销。
B． 由client自己负责触发notify，这样client可以在设定一系列state之后再一次性触发notify，可以避免过多的更新开销。缺点是client可能会忘了进行notify。
4， subject在通过update对observer进行更新的时候，是否提供详细的情报，有一个权衡：
A． 极端地，subject提供足够详细的情报，这是一种push model。缺点是，降低了observer的再利用性，因为subject对observer进行了某种假设。
B． 另一个极端，subject不提供任何的情报，这是一个pull model。缺点是，observer需要花很大的力气去找出是什么东西进行了更新。
5， 可以进行一种扩展，observer在attach的时候，给subject提供一个参数(aspect)，告诉subject它只对什么东西(event)被更新了感兴趣；这样，subject在某个event被更新的时候，只update那些对该event感兴趣的observer，同时update也带上aspect参数，告诉observer是什么event被更新了。
6， 如果subject和observer之间的关系太过于复杂，可以利用Mediator模式创建一个ChangeManager来协调它们之间的关系。
参考资料
《Design Pattern》 Gang-Of-4 1997
