一、引子
还记得警匪片上，匪徒们是怎么配合实施犯罪的吗？一个团伙在进行盗窃的时候，总 有一两个人在门口把风——假设有什么风吹草动。则会马上通知里面的同伙紧急撤退。
或许放风的人并不一定认识里面的每个同伙。而在里面或许有新来的小弟不认识这个放风的。可是这没什么，这个影响不了他们之间的通讯。由于他们之间有早已商定好的暗号。
呵呵，上面提到的放风者、偷窃者之间的关系就是观察者模式在现实中的活生生的样例。
二、定义与结构
观察者（Observer）模式又名公布-订阅（Publish/Subscribe）模式。GOF给观察者模式例如以下定义：定义对象间的一种一对多的依赖关系。当一个对象的状态发生改变时，全部依赖于它的对象都得到通知并被自己主动更新。
在这里先讲一以下向对象设计的一个重要原则——单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下。一个对象仅仅做一件事情。
这样在开发中也就带来了诸多的优点：提供了重用性和维护性，也是进行重构的良好的基础。
因此差点儿全部的设计模式都是基于这个主要的设计原则来的。观察者模式的起源我认为应该是在GUI和业务数据的处理上，由于如今绝大多数解说观察者模式的样例都是这一题材。可是观察者模式的应用决不仅限于此一方面。
以下我们就来看看观察者模式的组成部分。
1) 抽象目标角色（Subject）：目标角色知道它的观察者，能够有随意多个观察者观察同一个目标。而且提供注冊和删除观察者对象的接口。
目标角色往往由抽象类或者接口来实现。
2) 抽象观察者角色（Observer）：为那些在目标发生改变时须要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。
3) 详细目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer对象。当它的状态发生改变时, 向它的各个观察者发出通知。
4) 详细观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。在本角色内也能够维护一个指向Concrete Subject对象的引用。
放上观察者模式的类图。这样能将关系清晰的表达出来。
能够看得出来，在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的四个方法
//填充方法的行为非常easy的说
/**
* @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);
……
四、使用情况
GOF给出了以下使用观察者模式的情况：
1) 当一个抽象模型有两个方面, 当中一个方面依赖于另一方面。
将这二者封装在独立的对象中以使它们能够各自独立地改变和复用。
2) 当对一个对象的改变须要同一时候改变其他对象, 而不知道详细有多少对象有待改变。
3) 当一个对象必须通知其他对象，而它又不能假定其他对象是谁。换言之, 你不希望这些对象是紧密耦合的。
事实上观察者模式同前面讲过的桥梁、策略有着共同的使用环境：将变化独立封装起来，以达到最大的重用和解耦。
观察者与后两者不同的地方在于，观察者模式中的目标和观察者的变化不是独立的，而是有着某些联系。
五、我推你拉
观察者模式在关于目标角色、观察者角色通信的详细实现中。有两个版本号。一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色假设想要知道详细的变化细节。则就要自己从目标角色的接口中得到。这样的模式被非常形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。
另一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同一时候，通过一个參数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要。先给你啦。
这两种模式的使用。取决于系统设计时的须要。
假设目标角色比較复杂。而且观察者角色进行更新时必须得到一些详细变化的信息，则“推模式”比較合适。假设目标角色比較简单。则“拉模式”就非常合适啦。
六、总结
大概的介绍了下观察者模式。希望能对你有所帮助。