一、介绍，定义
观察者模式是一个使用频率非常高的模式，它最常用的地方是 GUI 系统、订阅–发布系统。因为这个模式的一个重要作用就是解耦，将被观察者和观察者解耦，使得他们之间的依赖性更小，甚至做到毫无依赖。以 GUI 系统来说，应用的 UI 具有易变性，尤其是前期随着业务的改变或者产品的需求修改，应用界面也会经常性变化，但是业务逻辑基本变化不大，此时， GUI 系统需要一套机制来应对这种情况，使得 UI 层与具体的业务逻辑解耦，观察者模式此时就派上用场了。
定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
二、使用场景
关联行为场景，需要注意的是，关联行为是可拆分的，而不是“组合”关系；
事件多级触发场景；
跨系统的消息交换场景，如消息队列、事件总线的处理机制。
三、UML类图
角色介绍：
Subject: 抽象主题，也就是被观察（Observable）的角色，抽象主题角色把所有观察者对象的引用保存在一个集合里，每个主题都可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察者对象。
ConcreteSubject: 具体主题，该角色将有关状态存入具体观察者对象，在具体主题的内部状态发生改变时，给所有注册过的观察者发出通知，具体主题角色又叫做具体被观察者（ConcreteObservable）角色。
Observer:抽象观察者，该角色是观察者的抽象类，它定义了一个更新接口，使得在得到主题的更改通知时更新自己。
ConcreteObserver: 具体的观察者，该角色实现抽象观察者角色所定义的更新接口，以便在主题的状态发生变化时更新自身的状态。
四、简单实现
下面让我们来简单模拟一下开发技术前线的发布–订阅过程：
//程序员是观察者
public class Coder implements Observer {
public String name;
public Coder(String aName) {
name = aName;
}
@Override
public void update(Observable o, Object arg) {
System.out.println("Hi, " + name + ", DevTechFrontier 更新啦，内容 ：" + arg);
}
@Override
public String toString() {
return "码农 ：" + name;
}
}
//DevTechFrontier 即开发技术前线，这个网站是被观察者角色，
//当他有更新时所有的观察者（这里是程序要）都会接收到相应的通知
public class DevTechFrontier extends Observable {
public void postNewPublication(String content) {
//标识状态或者内容发生改变
setChanged();
//通知所有观察者
notifyObservers(content);
}
}
//测试代码
public class Test {
public static void main(String[] args) {
//被观察的角色
DevTechFrontier devTechFrontier = new DevTechFrontier();
//观察者
Coder mrsimple = new Coder("mr.simple");
Coder coder1 = new Coder("coder-1");
Coder coder2 = new Coder("coder-2");
Coder coder3 = new Coder("coder-3");
//将观察者注册到可观察对象的观察者列表中
devTechFrontier.addObserver(mrsimple);
devTechFrontier.addObserver(coder1);
devTechFrontier.addObserver(coder2);
devTechFrontier.addObserver(coder3);
//发布消息
devTechFrontier.postNewPublication("新的一期开发技术前线周报发布啦！");
}
}
结果
可以看到所有订阅了开发技术前线的用户都收到了更新消息，一对多的订阅–发布系统就完成了。
Observer 和 Observable 是 JDK 中的内置类型，可见观察者模式是非常重要的，这里 Observer 是抽象的观察者角色，Coder 扮演的是具体观察者的角色：Observable 对应的是抽象主题角色，DevTechFrontier 则是具体的主题角色。Coder 是具体的观察者，它们订阅了 DevTechFrontier 这个具体的可观察对象，当 DevTechFrontier 有更新时，会遍历所有观察者（这里是Coder）, 然后给这些观察者发布一个更新的消息，即调用 Coder 中的 update 方法，这样就达到了一对多的通知功能。在这个过程中，通知系统都是依赖 Observer 和 Observable 这些抽象类，因此，对于 Coder 和 DevTechFrontier 完全没有耦合，保证了订阅系统的灵活性、可扩展性。
*有关 Observer 和 Observable 详情 可见https://blog.csdn.net/yangchuanan/article/details/87872625
五、模式的优缺点:
观察者模式主要的作用就是对象解耦，将观察者与被观察者完全隔离，只依赖于 Observer 和 Observer抽象，例如，ListView 就是运用了 Adapter 和观察者模式使得它的可扩展性、灵活性非常强，而耦合度却很低，这是设计模式在 Android 源码中优秀运用的典范。那么为什么 Android 架构师们会这样设计 ListView, 他们如何达到底耦合、高灵活性呢？广播接收器和事件总线在观察者模式上有什么相似之处，又有什么不同？
优点：
1、观察者和被观察者之间是抽象耦合，应对业务变化；
2、增强系统灵活性，可扩展性。
缺点：
在应用观察者模式时需要考虑一下开发效率和运行效率问题，程序中包括一个被观察者、多个观察者、开发和调试等内容会比较复杂，而且在 Java 中消息的通知默认是顺序执行，一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般考虑采用异步的方式。
