设计模式：观察者模式 ——— 城管来了，摊主快跑

前言
观察者模式
- 定义
- 通用类图
- 实际例子
  - 抽象被观察者
  - 具体被观察者
  - 抽象观察者
  - 具体观察者
  - 场景类
总结
- 优点
- 缺点
参考：

前言

时间飞逝，转眼初夏已过，尤记得以前读大学的时候，夏季最快乐的时光就是和小伙伴们在球场上打完球后去校门附近的烧烤摊撸串喝酒，那种感觉真是大快人心，怎一个爽字了得。不过有时也会遇到特殊情况，在撸串时摊主突然告知要收摊，连忙向我们赔礼道歉，原因是城管将至。我们无奈只能中断撸串过程，带着无法尽兴的郁闷心情离开.......

好吧，扯远了，说那么多废话也是想介绍两个角色，城管和烧烤摊主，这两个角色其实就相当于观察者模式中的被观察者和观察者，他们的活动过程其实就类似于观察者模式。

观察者模式

开始介绍观察者模式，毫无疑问，先说下它的定义。

定义

定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

其实就是发布-订阅模式，在实际的项目中非常的常见，比如微信公众号的消息推送就是观察者模式的最直接的应用。

通用类图

上面的类图包含了四个角色，分别是：

Subject 抽象被观察者：定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。
Observer 抽象观察者：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。
ConcreteSubject 具体被观察者：定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。
ConcreteObserver 具体观察者：实现抽象观察者角色所需要的更新接口，各个观察者有自己的处理逻辑。

实际例子

讲完了观察者模式的角色后，我们用实战例子来演示一下，就拿城管和小摊摊主举例好了，城管对应着观察者模式中的被观察者，而摊主就对应着观察者。OK，角色分配好了，我们开始写代码吧。

抽象被观察者

public abstract class Subject {//定义一个观察者数组private List<Observer> obs = new ArrayList<>();//增加一个观察者public void addObserver(Observer o) {this.obs.add(o);}//删除一个观察者public void delObserver(Observer o) {this.obs.remove(o);}//通知所有观察者public void notifyObservers() {for (Observer o : this.obs) {o.update();}}
}

具体被观察者

也就是城管，不知道英文怎么拼，用Police代替了，

public class Police extends Subject {public void chase(){System.out.println("城管：我要来了，还不走");// 通知所有观察者notifyObservers();}
}

抽象观察者

public interface Observer {/*** 通知更新* @param message*/void update(String message);
}

具体观察者

public class Vendor implements Observer {private String name;private String message;public Vendor(String name) {this.name = name;}@Overridepublic void update(String message) {System.out.println(name + " 收到： " + message);}
}

场景类

最后用一个场景类验证一下，

public class Client {public static void main(String[] args) {// 城管--被观察者Police police = new Police();// 烧烤摊主--观察者Observer barbecueVendor = new Vendor("烧烤摊主");// 手抓饼摊主--观察者Observer cakeVendor = new Vendor("手抓饼摊主");System.out.println("=======增加两个观察者=======");police.addObserver(barbecueVendor);police.addObserver(cakeVendor);police.chase();System.out.println("=======删除一个观察者=======");police.delObserver(cakeVendor);police.chase();}
}

定义一个城管对象和两个摊主对象，然后执行通知更新的操作，结果如下：

=======增加两个观察者=======
城管：我要来了，还不走
烧烤摊主 收到： 城管要来了，大家跑啊
手抓饼摊主 收到： 城管要来了，大家跑啊
=======删除一个观察者=======
城管：我要来了，还不走
烧烤摊主 收到： 城管要来了，大家跑啊

可以看到，我们的代码能正常增删观察者角色，同时也能通知消息更新，也算是重现了了观察者模式的流转过程。

总结

优点

1、观察者和被观察者之间抽象耦合。不管是增加观察者还是被观察者都非常容易扩展，而且在Java中都已经实现的抽象层级的定义，在系统扩展方面更是得心应手。

2、对象之间的保持高度的协作。当被观察者发生变化时，所有被观察者都会通知到，然后做出相应的动作。

缺点

1、如果观察者太多，被观察者通知观察者消耗的时间很多，同时开发和调试会比较复杂，影响系统的性能。

2、在Java中消息的通知默认是顺序执行，当某一观察者错误时就会导致系统卡壳，因此一般会采用异步方式。

参考：

《设计模式之禅》