二、定义与结构
在这里先讲一下面向对象设计的一个重要原则——单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下,一个对象只做一件事情。这样在开发中也就带来了诸多的好处:提供了重用性和维护性,也是进行重构的良好的基础。
因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在GUI和业务数据的处理上,因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。
下面我们就来看看观察者模式的组成部分。
可以看得出来,在Subject这个抽象类中,提供了上面提到的功能,而且存在一个通知方法:notify。还可以看出来Subject和ConcreteSubject之间可以说是使用了模板模式(这个模式真是简单普遍到一不小心就用到了)。
这样当具体目标角色的状态发生改变,按照约定则会去调用通知方法,在这个方法中则会根据目标角色中注册的观察者名单来逐个调用相应的update方法来调整观察者的状态。这样观察者模式就走完了一个流程。
在下面的例子中会更深刻的体验到这个流程的。
三、举例
观察者模式是我在《JUnit源代码分析》中遗留的一个模式,因此这里将采用JUnit来作为例子。
JUnit为用户提供了三种不同的测试结果显示界面,以后还可能会有其它方式的现实界面……。怎么才能将测试的业务逻辑和显示结果的界面很好的分离开?不用问,就是观察者模式!
下面我们来看看JUnit中观察者模式的使用代码:
//下面是我们的抽象观察者角色,JUnit是采用接口来实现的,这也是一般采用的方式。
//可以看到这里面定义了四个不同的update方法,对应四种不同的状态变化
public interface TestListener {
/**
* An error occurred.
*/
public void addError(Test test, Throwable t);
/**
* A failure occurred.
*/
public void addFailure(Test test, AssertionFailedError t);
/**
* A test ended.
*/
public void endTest(Test test);
/**
* A test started.
*/
public void startTest(Test test);
}
//具体观察者角色,我们采用最简单的TextUI下的情况来说明(AWT,Swing对于整天做Web应用的人来说,已经很陌生了)
public class ResultPrinter implements TestListener {
//省略好多啊,主要是显示代码
……
//下面就是实现接口TestListener的四个方法
//填充方法的行为很简单的说
/**
* @see junit.framework.TestListener#addError(Test, Throwable)
*/
public void addError(Test test, Throwable t) {
getWriter().print("E");
}
/**
* @see junit.framework.TestListener#addFailure(Test, AssertionFailedError)
*/
public void addFailure(Test test, AssertionFailedError t) {
getWriter().print("F");
}
/**
* @see junit.framework.TestListener#endTest(Test)
*/
public void endTest(Test test) {
}
/**
* @see junit.framework.TestListener#startTest(Test)
*/
public void startTest(Test test) {
getWriter().print(".");
if (fColumn++ >= 40) {
getWriter().println();
fColumn= 0;
}
}
}
来看下我们的目标角色,随便说下,由于JUnit功能的简单,只有一个目标——TestResult,因此JUnit只有一个具体目标角色。
//好长的代码,好像没有重点。去掉了大部分与主题无关的信息
//下面只列出了当Failures发生时是怎么来通知观察者的
public class TestResult extends Object {
//这个是用来存放测试Failures的集合
protected Vector fFailures;
//这个就是用来存放注册进来的观察者的集合
protected Vector fListeners;
public TestResult() {
fFailures= new Vector();
fListeners= new Vector();
}
/**
* Adds a failure to the list of failures. The passed in exception
* caused the failure.
*/
public synchronized void addFailure(Test test, AssertionFailedError t) {
fFailures.addElement(new TestFailure(test, t));
//下面就是通知各个观察者的addFailure方法
for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) {
((TestListener)e.nextElement()).addFailure(test, t);
}
}
/**
* 注册一个观察者
*/
public synchronized void addListener(TestListener listener) {
fListeners.addElement(listener);
}
/**
* 删除一个观察者
*/
public synchronized void removeListener(TestListener listener) {
fListeners.removeElement(listener);
}
/**
* 返回一个观察者集合的拷贝,当然是为了防止对观察者集合的非法方式操作了
* 可以看到所有使用观察者集合的地方都通过它
*/
private synchronized Vector cloneListeners() {
return (Vector)fListeners.clone();
}
……
}
嗯,观察者模式组成所需要的角色在这里已经全了。不过好像还是缺点什么……。呵呵,对!就是它们之间还没有真正的建立联系。在JUnit中是通过TestRunner来作的,而你在具体的系统中可以灵活掌握。
看一下TestRunner中的代码:
public class TestRunner extends BaseTestRunner {
private ResultPrinter fPrinter;
public TestResult doRun(Test suite, boolean wait) {
//就是在这里注册的
result.addListener(fPrinter);
……
四、使用情况
五、我推你拉
观 察者模式在关于目标角色、观察者角色通信的具体实现中,有两个版本。一种情况便是目标角色在发生变化后,仅仅告诉观察者角色“我变化了”;观察者角色如果 想要知道具体的变化细节,则就要自己从目标角色的接口中得到。这种模式被很形象的称为:拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出 来的。
还有一种方法,那就是我目标角色“服务一条龙”,通知你发生变化的同时,通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要,先给你啦。
这两种模式的使用,取决于系统设计时的需要。如果目标角色比较复杂,并且观察者角色进行更新时必须得到一些具体变化的信息,则“推模式”比较合适。如果目标角色比较简单,则“拉模式”就很合适啦。
注:以上内容来自网络,本人不承担连带责任...
本帖转自:http://blog.csdn.net/hangke/archive/2007/10/10/1818471.aspx