本篇文章分为两部分，其中第一部分介绍什么是观察者模式，第二部分介绍观察者模式值得思考的地方。

第一部分-观察者模式介绍

一.定义

指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。

二.解决的问题

一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。

三.使用场景

一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知

四.优缺点

1：优点：

1. 降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。
2. 目标与观察者之间建立了一套触发机制。

2：缺点：

1. 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
2. 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。

五.结构

实现观察者模式时要注意具体目标对象和具体观察者对象之间不能直接调用，否则将使两者之间紧密耦合起来，这违反了面向对象的设计原则中的依赖倒置原则。

1、观察者模式的主要角色如下

1. 抽象主题（Subject）角色：也叫抽象目标类，它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法，以及通知所有观察者的抽象方法。
2. 具体主题（Concrete Subject）角色：也叫具体目标类，它实现抽象目标中的通知方法，当具体主题的内部状态发生改变时，通知所有注册过的观察者对象。
3. 抽象观察者（Observer）角色：它是一个抽象类或接口，它包含了一个更新自己的抽象方法，当接到具体主题的更改通知时被调用。
4. 具体观察者（Concrete Observer）角色：实现抽象观察者中定义的抽象方法，以便在得到目标的更改通知时更新自身的状态。

2、观察者模式的结构图如图所示：

六.实现

代码如下所示：
1：抽象目标：

2：具体目标：

3：抽象观察者：

4：观察者1：

5：观察者2：

6：方法调用：

7：结果：

以上就是对观察者模式的介绍。接下来说一下观察者模式值得思考的地方。

第二部分-观察者模式思考点

1：用于系统内部：
我个人不太建议在系统(服务)内部使用观察者，原因有二：

1. 增加了代码的复杂度和维护成本。
2. 开发人员本来就需要熟悉这个系统内部的代码。

2：用于系统(服务)之间：
例如薪酬系统和考勤系统，员工的工资是在薪酬系统里的，但是薪酬的计算是需要受到考勤系统的制约，如果员工旷工了，那么考勤系统就会发一条消息，告诉薪酬系统某个员工某天旷工了，薪酬系统收到消息后就会减少该员工的月工资。
这种场景使用观察者模式有两大优点：

1. 从项目设计的角度来看，既能实现功能，又能够降低两个系统之间的耦合度。
2. 从项目维护者(开发人员)的角度看，完全不需要管其他系统的业务实现，降低了学习成本，把主要精力都放到本系统中。