设计模式目前分为23种三大类，而观察者模式作为开发设计中常用的代码设计模式之一,属于行为模式中的一种,也是我们众多开发最容易掌握应用的一种，今天我们来聊一聊观察者模式。

观察者模式的定义

观察者模式（Observer Design Pattern）：在对象之间定义一个一对多的依赖，当一个对象状态改变的时候，所有依赖的对象都会得到通知并自动更新。简单点来说就是当某个对象发生改变时，这个对象的所有观察者都会做出相应的改变。

举个例子，当你干项目时，一旦你的进度发生改变，盯着这项目的领导们，会根据项目的进度做出不同的计划策略。当进度慢时，产品催着你加班赶进度，市场做好规划预宣传，人事继续招人……

Subject（被观察者）

定义被观察者必须实现的职责， 它可以动态地增加、 删除观察者。它的两大主要作用是：管理观察者并通知观察者。

Observer（观察者）

观察者接收到变更消息后，就会进行对应的方法操作，对接收到的信息进行处理。

ConcreteSubject（被观察者的实现类）

定义被观察者自己的业务逻辑， 同时定义对哪些事件进行通知。

ConcreteObserver（观察者具体实现）

每个观察者在接收到消息后的处理反应是不同，各个观察者有自己的处理逻辑。

Code Time

接下来我们用代码简单实现一下图一的中观察者模式，首先我们创建一个被观察者父类Subject，里面包括观察者的添加移除以及触发变化事件；

然后创建一个观察者的的父类接口Observer，里面包含被观察者发生变化时，观察者需做出对应变化的事件；

接下来，定义一个Me继承自Subject的被察者类，里面有做项目doProject和一个判断方法，当出现delay时，就通知项目的其他人项目延期了，要做出对应的措施了；

这里我就简单举例写HR\PM\OM三个类型的观察者了，如果需要其他观察者类型，再实现Observer接口即可。

最后，我们来测试一下代码，先创建一个张三的被观察者类，然后分别创建HR、PM、OM的观察者，加入观察张三的队列，最后在被观察者张三执行逻辑时，触发监听改变的事件，所有加入观察张三的观察者触发自己相应的逻辑。

运行上述代码的结果是：

干活的张三因为项目延期了，其他观察张三的观察者果然都做出了自己的处理，HR招人，PM催加班，市场重新规划……

观察者模式的优缺点优点观察者模式在被观察者和观察者之间建立一个抽象的耦合关系，被观察者不需要知道自己被多少观察者观察，当需要添加新的观察者时，只需添加到观察者的队列中去即可，代码可扩展性较好观察者模式支持广播通讯，被观察者会向所有的登记过的观察者发出通知缺点如果一个被观察者对象有较多的直接或间接的观察者的话，通知花费时间较长，性能下降如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，可能会直接导致系统崩溃。在同步通知观察者时，如果其中一个发生异常，可能导致后续通知处理失败。如果对观察者的通知是通过另外的线程进行异步通知的话，系统必须保证通知的可靠性虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。应用场景监听器的实现就是使用了观察者模式，比如SpringMVC中的ServletContextListener等关联变化的业务场景，比如某业务改变某个属性，另外一个字段也必须跟着改变，并且未来业务还有更多的关联字段变化，这个时候使用观察者模式会有较好地扩展。跨系统的消息传递交换，比如消息队列的处理机制，里面大量运用了观察者模式总结

观察者模式是一种比较容易理解的代码设计模式之一，在很多框架中都运用到它，比如Spring、Tomcat、MQ设计中都有大量使用。虽然理解简单，但用得好却也不容易，比如需要考虑使用异步通知提高性能时通知可靠性等因素。