Client端的实现:
Observer模式的变种:如果Observer不需要知道自己观察的具体Subject对象,那么UML可以简化为: Subject类不用修改 Observer类需要加一个方法,用于将自身添加到Subject集合中
于是ConcreteObserver就简化到只需要实现Update()方法了
一个现实中的例子:猫叫了,于是老鼠吓跑了,主人惊醒了。我们可以使用event实现,也可以直接使用Observer实现,二者的原理是相同的。 基于委托的Observer模式:解除Observer与Subject之间的耦合关系,从而Observer不必有同样的接口 在实现上只需要更改Subject类,并增加一个delegate如下:
于是Client端调用:
观察者模式的效果有以下几个优点:
(1)观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体现察者聚集,每一个具体现察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者,它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起,因此它们可以属于不同的抽象化层次。
(2)观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。
观察者模式有下面的一些缺点:
(1)如果一个被观察者对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间。
(2)如果在被观察者之间有循环依赖的话,被观察者会触发它们之间进行循环调用,导致系统崩溃。在使用观察考模式时要特别注意这一点。
(3)如果对观察者的通知是通过另外的线程进行异步投递的话,系统必须保证投递是以自恰的方式进行的——这时要加额外的同步锁。
(4)虽然观察者模式可以随时使观察者知道所观察的对象发生了变化,但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。