设计模式:观察者模式（Observer）

引子

还记得警匪片上，匪徒们是怎么配合实施犯罪的吗？一个团伙在进行盗窃的时候，总有一两个人在门口把风——如果有什么风吹草动，则会立即通知里面的同伙紧急撤退。也许放风的人并不一定认识里面的每一个同伙；而在里面也许有新来的小弟不认识这个放风的。但是这没什么，这个影响不了他们之间的通讯，因为他们之间有早已商定好的暗号。呵呵，上面提到的放风者、偷窃者之间的关系就是观察者模式在现实中的活生生的例子。

定义与结构

观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF 给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

在这里先讲一下面向对象设计的一个重要原则——单一职责原则。系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。

因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在GUI 和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。

下面我们就来看看观察者模式的组成部分。

1) 抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。

2) 抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。

3) 具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer 对象。当它的状态发生改变时, 向它的各个观察者发出通知。

4) 具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer 的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向Concrete Subject 对象的引用。

放上观察者模式的类图，这样能将关系清晰的表达出来。

观察者模式的实现

下面是一个猎头的典型例子。这个图中有2个角色-猎头和求职者。求职者先在猎头处注册，当有新的工作机会时猎头就会通知求职者。

//抽象目标角色--Subject
public interface Subject {
public void registerObserver(Observer o);
public void removeObserver(Observer o);
public void notifyAllObservers();
}
//具体目标角色--Concrete Subject
public class HeadHunter implements Subject {
private ArrayList<Observer> userList;
private ArrayList<String> jobs;

public HeadHunter() {
userList = new ArrayList<Observer>();
jobs = new ArrayList<String>();
}

@Override
public void registerObserver(Observer o) {
// TODO Auto-generated method stub
userList.add(o);
}

@Override
public void removeObserver(Observer o) {
// TODO Auto-generated method stub
userList.remove(o);
}

@Override
public void notifyAllObservers() {
// TODO Auto-generated method stub

for (Observer o : userList) {
o.update(this);
}
}

public void addJob(String job) {
this.jobs.add(job);
notifyAllObservers();
}

public ArrayList<String> getJobs() {
return jobs;
}

public String toString() {
return jobs.toString();
}

}
//抽象观察者角色--Observer
public interface Observer {
public void update(Subject s);
}
//具体观察者角色--Concrete Observer
public class JobSeeker implements Observer {

private String name;

public JobSeeker(String name) {
this.name = name;
}

@Override
public void update(Subject s) {
// TODO Auto-generated method stub
System.out.println(this.name + " got notified!");
// print job list
System.out.println(s);
}

}

//客户端测试
public class TestClient {
public static void main(String[] args) {
// TODO Auto-generated method stub
HeadHunter hh = new HeadHunter();
hh.registerObserver(new JobSeeker("Mike"));
hh.registerObserver(new JobSeeker("Chris"));
hh.registerObserver(new JobSeeker("Jeff"));
// 每次添加一个个job，所有找工作人都可以得到通知。
hh.addJob("Google Job");
hh.addJob("Yahoo Job");
}
}

验证输出

Mike got notified!
[Google Job]
Chris got notified!
[Google Job]
Jeff got notified!
[Google Job]
Mike got notified!
[Google Job, Yahoo Job]
Chris got notified!
[Google Job, Yahoo Job]
Jeff got notified!
[Google Job, Yahoo Job]

我推你拉

观察者模式在关于目标角色、观察者角色通信的具体实现中，有两个版本。一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色如果想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。

还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。

这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适啦。