| 1、概念
观察者模式是对象的行为模式，外号非常多...！！又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
2、针对的问题
被观察者对象在状态变化时，通知所有观察者对象，使它们能够自动更新自己。保证整体的数据一致性。此种模式通常被用来实现事件处理系统。
适用性：
1）. 当一个抽象模型有两个方面,其中一个方面依赖于另一方面。将这二者封装在独立的对 象中以使它们可以各自独立地改变和复用。
2）. 当对一个对象的改变需要同时改变其它对象,而不知道具体有多少对象有待改变。
3）. 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。
3、角色组成
1、抽象主题(Subject)角色：
抽象主题角色把所有对观察者对象的引用保存在一个聚集（比如ArrayList对象）里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，抽象主题角色又叫做抽象被观察者(Observable)角色。
2、具体主题(ConcreteSubject)角色：
将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete
Observable)角色。
3、抽象观察者(Observer)角色：
为所有的具体观察者定义一个接口，在得到主题的通知时更新自己，这个接口叫做更新接口。
4、具体观察者(ConcreteObserver)角色：
存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态
像协调。如果需要，具体观察者角色可以保持一个指向具体主题对象的引用。
4、举例说明
4.1、例子描述
该实例模拟了烧水的过程，涉及三个对象，Heater(热水器)，Display（显示器），Alarm(报警器)。模拟过程：为了便于运行，水的初始化温度为90，沸点为100，显示器依据热水器显示温度，显示器显示温度为100时，报警器开始报警。明显可以看出Heater是subject
,Display 是它的 Obsrver，同时Display亦是subject，因为它要被报警器观察，所以Alarm是Display的Observer.
4.2、类图
（PS：如果不知道各种符号的意思，看这里——http://blog.csdn.net/zhshulin/article/details/18088633）
4.3、源码
Subject：抽象被观察者
package org.zsl.designmodel.observer;
import java.util.ArrayList;
import java.util.List;
/**
* 被观察者角色
* @author ZSL
*
*/
public abstract class Subject {
private List<Observer> list = new ArrayList<Observer>();
/**
* 注册观察者对象
* @param observer 观察者
*/
public void registerObserver(Observer observer){
list.add(observer);
System.out.println("注册了一个观察者角色！");
}
/**
* 删除观察者对象
* @param observer 观察者
*/
public void removeObserver(Observer observer){
list.remove(observer);
}
/**
* 通知所有注册的观察者对象，我的状态改变咯
* @param newState
*/
public void notifyAllObservers(String newState){
for(Observer observer : list){
observer.update(newState);
}
}
}
|
Observer ：观察者接口，只有一个update()方法
package org.zsl.designmodel.observer;
/**
* 观察者接口
* @author ZSL
*
*/
public interface Observer {
/**
* 更新接口
* @param state 更新的状态
*/
public void update(String state);
} |
Heater：热水器，一个具体被观察者
package org.zsl.designmodel.observer;
public class Heater extends Subject {
private int temperature;
public int getTemperature() {
return temperature;
}
public void setTemperature(int temperature) {
this.temperature = temperature;
}
public void boilWater(){
for(int i=95;i<105;i++){
temperature = i;
this.setTemperature(temperature); //设置新的温度
this.notifyAllObservers(Integer.toString(temperature)); //通知所有注册的观察者
}
}
}
|
Display：既是观察者，又是被观察者
package org.zsl.designmodel.observer;
/**
* 显示器，既是观察者又是被观察者
* @author Administrator
*
*/
public class Display extends Subject implements Observer {
private boolean isBoiled = false; //表示水是否烧开了
private int displayTemperature; //定义显示器的温度
public boolean isBoiled() {
return isBoiled;
}
public void setBoiled(boolean isBoiled) {
this.isBoiled = isBoiled;
}
@Override
public void update(String state) {
displayTemperature = Integer.parseInt(state);
System.out.println("当前显示器显示的温度是："+displayTemperature);
this.displayTemperature(displayTemperature);
}
private void displayTemperature(int temperature){
if(temperature>100){
this.setBoiled(true);
this.notifyAllObservers(Boolean.toString(isBoiled));
}
}
} |
Alerm：只是观察者
package org.zsl.designmodel.observer;
public class Alarm implements Observer {
private String observerState; //定义观察者的状态
@Override
public void update(String state) {
Boolean flag = Boolean.parseBoolean(state);
if(flag){
System.out.println("报警器响了，水温超过100度了。");
}
}
}
|
测试
package org.zsl.designmodel.observer;
public class Test {
public static void main(String[] args) {
Heater heater = new Heater();
Display display = new Display();
Alarm alarm = new Alarm();
heater.registerObserver(display);
display.registerObserver(alarm);
heater.boilWater();
}
} |
结果：
5、优点
a、支持松耦合和减少依赖性
客户端不再依赖于观察器，因为通过使用主体和 Observer 接口对客户端进行了隔离。 许多框架具有此优点，在这些框架中的应用程序组件可以注册为当（低级）框架事件发
生时得到通知。结果，框架将调用应用程序组件，但不会依赖于它。
b、提高了应用程序的可维护性和重用性
面向对象设计的一个原则是：系统中的每个类将重点放在某一个功能上，而不是其他方面。一个对象只做一件事情，并且将他做好。观察者模式在模块之间划定了清晰的界限，提高了应用程序的可维护性和重用性。
c、观察器数目可变
观察器可以在运行时附加和分离，因为主体对于观察器数目没有任何假定。此功能在这样的情况下是很有用的：观察器数在设计时是未知的。例如，如果用户在应用程序中打开的每个窗口都需要一个观察器。
6、缺点
a、性能降低。
在许多实现中，观察器的 update() 方法可能与主体在同一线程中执行。如果观察器列表很长，则执行
Notify() 方法可能需要很长时间。抽取对象依赖性并不意味着添加观察器对应用程序没有任何影响。
b、内存泄漏。
在 Observer 中使用的回调机制（当对象注册为以后调用时）会产生一个常见的错误，从而导致内存泄漏，甚至是在托管的
C# 代码中。假定观察器超出作用范围，但忘记取消对主体的订阅，那么主体仍然保留对观察器的引用。此引用防止垃圾收集在主体对象也被破坏之前重新分配与观察器关联的内存。如果观察器的生存期比主体的生存期短得多（通常是这种情况），则会导致严重的内存泄漏。
c、隐藏的依赖项。
观察器的使用将显式依赖性（通过方法调用）转变为隐式依赖性（通过观察器）。如果在整个应用程序中广泛地使用观察器，则开发人员几乎不可能通过查看源代码来了解所发生的事情。这样，就使得了解代码更改的含意非常困难。此问题随传播级别急剧增大（例如，充当
Subject 的观察器）。因此，应该仅在少数定义良好的交互（如 Model-View-Controller
模式中模型和视图之间的交互）中使用观察器。最好不要在域对象之间使用观察器。
d、测试 / 调试困难。
尽管松耦合是一项重大的体系结构功能，但是它可以使开发更困难。将两个对象去耦的情况越多，在查看源代码或类的关系图时了解它们之间的依赖性就越难因此，仅当可以安全地忽略两个对象之间的关联时才应该将它们松耦合（例如，如果观察器没有副作用）。 |
