以前做一个界面的时候常常会遇到这样的尴尬情况:希望保留各个独立的组件(类),但又希望它们之间能够相互通信。譬如Windows中的Explorer,我们希望鼠标点击左边是树型目录的一个节点,右边的文件浏览能及时列出该节点目录下的文件和子目录,类似这样一个简单的应用,如果只有一个类继承JFrame,而树型组件和浏览文件的面板作为成员,就像:
public class MainFrame extends JFrame { JPanel treePanel; JTree tree; JPanel filePanel; ... } |
这样当然容易在两者之间传递消息,但是可扩展性较差。通常容易想到的是两种办法:在一个组件里保留另一个组件类型的成员,初始化时作为参数传入引用,比如:
class TreePanel extends JPanel { JTree tree; ... } class FilePanel extends JPanel { public FilePanel(JTree tree){...} ... } |
或者将一个组件线程化,不停地监听另一个组件的变化,然后作出相应的反映,比如:
class TreePanel extends JPanel { JTree tree; ... } class FilePanel extends JPanel implements Runnable { public void run() { while (true) { //监听tree的变化 } ... } ... } |
这样确实可以达到我们的目的,但是第一种方案显然不利于松散耦合,第二种方案比较占用系统资源。通过学习设计模式,我们发现可以用Observer模式来解决这个问题。
2. Observer模式
设计模式分为创建型、结构型和行为型,其中行为型模式专门处理对象间通信,指定交互方式等,Observer模式就是属于行为型的一种设计模式。按照“四人帮”(Gang of Four)在“Design Patterns”里的定义,Observer模式“定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新”,这个描述正好符合我们对“组件通信”问题的需求。让我们先看看Observer模式的结构:

其中各元素的含义如下:
- Subject:被观察的目标的抽象接口,它提供对观察者(Observer)的注册、注销服务,Notify方法通知Observer目标发生改变;
- Object:观察者的抽象接口,Update方法是当得到Subject状态变化的通知后所要采取的动作;
- ConcreteSubject:Subject的具体实现;
- ConcreteObserver:Observer的具体实现
3. Java中的Observer模式:Observer和Observable
在大致了解了Observer模式的描述之后,现在我们更为关心的是它在Java中是如何应用的。幸运的是,自从JDK 1.0起,就有了专门处理这种应用的API,这就是Observer接口和Observable类,它们是属于java.util包的一部分。看来Java的开发者们真是深谙设计模式的精髓,而Java的确是为了真正的面向对象而生的,呵呵!
这里的Observer和Observable分别对应设计模式中的Observer和Subject,对比一下它们定义的方法,痕迹还是相当明显的:
Observer的方法:
- update(Observable subject, Object arg) 监控subject,当subject对象状态发生变化时Observer会有什么响应,arg是传递给Observable的notifyObservers方法的参数;
- addObserver(Observer observer) observer向该subject注册自己
- hasChanged() 检查该subject状态是否发生变化
- setChanged() 设置该subject的状态为“已变化”
- notifyObservers() 通知observer该subject状态发生变化
其实在AWT/Swing事件模型中用到了好几种设计模式,以前的JDK 1.0 AWT使用的是“基于继承的事件模型”,在该模型Component类中定义了一系列事件处理方法,如:handleEvent,mouseDown,mouseUp等等,我们对事件的响应是通过对组件类继承并覆盖相应的事件处理方法的手段来实现,组件接收到事件向所在容器广播,沿着容器链直到发现事件被某个容器的handle方法所处理。这种模型有很多缺点,事件的处理不应当由事件产生者负责,而且根据“设计模式”一书中的原则,“继承”通常被认为是“对封装性的破坏”,父子类之间的紧密耦合关系降低了灵活性,同时继承容易导致家族树规模的庞大,这些都不利于组件可重用。
JDK 1.1以后新的事件模型是被成为“基于授权的事件模型”,也就是我们现在所熟悉的Listener模型,事件的处理不再由产生事件的对象负责,而由Listener负责,只有被注册过的Listener才能向组件传递事件动作。尤其在Swing组件中设计MVC结构时用到了Observer模式,众所周知,MVC表示“模型-视图-控制器”,即“数据-表示逻辑-操作”,其中数据可以对应多种表示,这样视图就处在了observer的地位,而model则是subject。大家所熟悉的JTree和JTable就是这种MVC结构:
-----------------------------------------------------
Model View Controller
-----------------------------------------------------
TreeModel JTree TreeModelListener
TableModel JTable TableModelListener
-----------------------------------------------------
5. 简单的例子
回到本文一开始的那个Explorer的例子,我们考虑做一个简单的图片浏览器,使树型选择组件和图片浏览面板在两个不同的类中,其中图片浏览面板根据所选择的树的节点显示相应的图片,所以图片浏览面板是一个observer,树是subject。由于Java单根继承的原因,我们不能同时继承JPanel和Observable,但可以用对象的组合把一个subject放到我们的类当中,并通过TreeSelectionListener触发subject的setChanged方法,并通过notifyObservers方法通知observer。
例子代码如下:
//LeftPanel.java package com.jungleford.test; import java.awt.BorderLayout; public final class LeftPanel extends JPanel class Sensor extends Observable |
//RightPanel.java package com.jungleford.test; import java.awt.*; public class RightPanel extends JPanel implements Observer |
//MainFrame.java package com.jungleford.test; import java.awt.*; public class MainFrame extends JFrame |
程序运行截图如下:

启动界面

点击Rabbit显示的图像

点击Devestator显示的图像
附录:Observer模式概览
摘自 设计模式
意图 | 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。 |
动机 | 将一个系统分割成一系列相互协作的类有一个常见的副作用:需要维护相关对象间的移植性。我们不希望为了维持一致性而使各类紧密耦合,因为这样将降低它们的可重用性。 |
适用性 |
|
结构图 | ![]() |
参与者 |
|
协作图 | ![]() |
效果 | 允许你独立的改变目标和观察者。你可以单独复用目标对象而无需同时复用其观察者,反之亦然。你也可以在不改动目标和其它观察者的前提下增加观察者 |
应用 | MVC模式 |
相关模式 |
|
参考资料:
- Design Patterns: Elements of Reusable Object-Oriented Software, by E. Gamma, R. Helm, R. Johnson, J. Vlissides
- IBM developerWorks教程:Java设计模式101
- Graphic Java 2, Mastering the JFC Volumn I: AWT, by David M. Geary