《设计模式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