观察者模式—GOF的23个之一

观察者模式—GOF的23个之一

 

前言：同样来自《Head First 设计模式》,不涉及任何商务往来。『观察者模式』——在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新。

 

一、认识观察者模式（资料）

我们看看报纸和杂志的订阅是怎么回事：

1、 报社的业务就是出版报纸。

2、向某家报社订阅报纸，只要他们有新报纸出版，就会给你送

来。只要你是他们的订户，你就会一直收到新报纸。

3、当你不想再看报纸的时候，取消订阅，他们就不会再送新报

纸来。

4、只要报社还在运营，就会一直有人（或单位）向他们订阅报

纸或取消订阅报纸。

认识：

报社就是可观察者，“你”就是观察者。

总体用“推”数据的形式。

后来有人提出：顾客想获取什么信息就获取什么信息，也就是说不要获取整份报纸，而只是报纸上某些内容。即要采取“拉”数据的形式。

经过思考，我觉得，顾客不会向报社说：我只要半份报纸。那对报社来说，就乱套了。

 

二、普通类（可观察者）调用多个类（观察者）遇到的问题：

1、一对多依赖，常规用一个实体类使用其他几个类。（针对具体实现编程，而非针对接口。）

2、每个观测者都得单独修改。（对于每个新的布告板，我们都得修改代码。）

3、观测者不能动态增加。（无法在运行时动态地增加（或删除）布告板。）

4、观测者没有实现统一的接口。（布告板没有实现一个共同的接口。）

5、普通编程中未封装改变的部分。

6、普通编程中侵犯了可观测者WeatherData类的封装。

 

 

 

三、推荐下面以“气象站”案例的类图：

（观测者模式--手写版）

即“推”数据的策略

 

（观察者模式--Java内置版）

即“拉”数据的策略

 

 

 

 

四、要点：

1、观察者模式定义了对象之间一对多的关系。

2、主题（也就是可观察者）用一个共同的接口来更新观察者。

3、观察者和可观察者之间用松耦合方式结合（loosecoupling），可观察者不知道观察者的细节，只知道观察者实现了观察者接口。

4、使用此模式时，你可从被观察者处推（push）或拉（pull）数据（然而，推的方式被认为更“正确”）。

5、有多个观察者时，不可以依赖特定的通知次序。

6、Java有多种观察者模式的实现，包括了通用的java.util.Observable。

7、要注意java.util.Observable实现上所带来的一些问题。

8、如果有必要的话，可以实现自己的Observable，这并不难，

不要害怕。

9、Swing大量使用观察者模式，许多GUI框架也是如此。

 

 

 

 

 

 

如有好的建议，可留言或发至笔者邮箱：[e-mail]