上一篇我们讲述了责任链模式，从上一篇中我们可以发现设计模式的几个好处
1）灵活性高，易于扩展，因为在审批者链中我们可以随机的添加审批人，也可以去掉或更换一个审批人。
2）低耦合，审批人之间相互独立，互不干涉。有一个审批者发生变化不会影响其他审批人的正常处理。
3）对修改关闭，当需要添加一个新的审批者时只需要继承handler类，然后将新的对象加到链中，不需要修改抽象类和其他审批者类。
通过上一篇的初识，我们对设计模式应该有一点感觉了，今天我们就来再学习一个新的设计模式-观察者设计模式！
1:什么是观察者模式
定义：一对多的对象关系，当目标对象发生变化时，依赖于它的所有对象都会得到通知并更新！
应用场景：大家都玩微信，肯定都有关注微信公众号，当我们关注了某一个公众号后，这个公众号就会每天给我们推送一次新的消息！同时如果我们取消了关注，就不会接收到消息！
场景分析：其实微信公众号号就是一个目标对象（subject），每个关注了该公众号的人就是一个观察者（observer），一旦公共号有了新的状态变更，就会推送给所有的用户！
类图：
从类图中可以看出，观察者模式的二个重要的接口，Subject, Observer, 二个实体类：ConcreteSubject, ConcreteObserver,
Subject接口：定义了目标对象的三个方法，主要用来让具体的主题来操作观察者，比如：添加观察者，删除观察者，通知观察者
ConcreteSubject：这个类就是具体的目标对象，实现主题（Subject）的三个接口，同时，具体的Subject也可以自定义一写属于自己的函数来获取，设置状态，属性
Observer：观察者的接口，只有一个Update的方法，当Subject状态发生变化时，这个方法就或被调用，并进行更新
ConcreteObserver：具体的观察者对象（实现了Observer的任意类），实现了Update方法，必须注册到具体的主题中才能接收主题发出来的更新。
2:如何实现观察者模式
上面描述了一大堆的文字，读完也许有点晕晕的，和上一篇一样，直接帖代码出来，debug一下，就会清晰很多了。下面举一个气象局更新，气温，湿度，光照强度的场景：
场景：有三个旅游公司他们为了每天依据天气状况给客户推荐好玩的地方，需要订阅气象局的天气信息，这时候就需要气象局来每天给这些签了合同的公司提供气象数据，而那些没有花钱订阅的公司就不会收到气象局的推送的气象数据。
1:首先创建目标接口，如下图所示：
2:创建具体目标类（气象站）然后实现目标接口
3:创建观察者接口
4:创建第一个app类（观察者）实现观察者接口
5:创建第二个app（观察者）类，同时实现观察者接口
6:创建测试类，
一：创建2个app类注册到目标类中，然后设置天气情况
二：将appone从目标类的列表中移除，从新设置天气状况
7:我们从下图可以看出来当观察者有二个时，气象数据发生更新后就会立即通知观察者。同的当我们把某一个观察者移除后，气象数据再发生更新就不会通知该观察者。
3:观察者的推模型和拉模型
通过上面代码的编写和演示我们已经认识了什么是观察者模式了。可以简单点理解就是在目标对象中维护一个观察者集合，当目标对象的状态发生了变化后通知观察者列表中的每一个观察者对象进行更新！
接下来我们思考这样一个场景，现在新增了一个appThree，但他只需要温度这一个数据，其他的数据都不需要。这时我们的观察者接口就不能用了（因为我们的观察者接口里的update方法有三个参数）
那如何解决这个问题呐？那就是我们观察者模式的变形，拉模型
推模型：由主题对象主动向观察者推送全部消息，不管观察者是不是需要全部的消息
拉模型：主题对象只推送少量消息给观察者，如果观察者需要更多的消息，需要自己去获取！
其实上面的代码就是一种推模型得演示，然后我们将主题对象和观察者的代码稍微改动一下来实现拉模型：
1：只修改我门的具体目标类，在NotifyObserver函数中，不在传递具体的气象参数而是改成当前的对象，如下图
2：修改观察者接口，updateMessage函数，参数改为目标的抽象对象，修改后的code,如下图：
3：修改APP one的 观察者类，该观察者只需要温度参数，
4:修改第二个观察者类，只接收，湿度参数
5:新增一个观察者，只接受，光照强度参数
6:在我们的测试类中，新建一个AppThree观察者，并注册到我们的目标实体类中，设置气象数据，运行后的接口如下图：
4:实现JDK中观察者模式
通过前面的学习我们已经认识了观察者模型的结构和使用了，其实在java的jdk中，提供了观察者接口和目标类给开发者使用的，下面我们就基于JDK中提供的Observable(目标类)和Observer(观察者接口)来实现一套新的观察者模式
1：新建一个目标类，并继承Observable（java.util.Observable）
通过上面的代码我们可以看出来，基于JDK的目标对象实现上，目标对象变的简单了很多，1）：我们不需要在目标对象里再去维护一个观察着的集合 2）：我们也不许要实现，观察者的添加，删除，通知的方法了，只需要调用在通知之前调用一下setChange()方法，然后直接调用notifyObservers 3 ）：在JDK中，有二个notifyObservers ，如果用拉模式使用无参数的，用推模式就使用有参数的（如上图中注释的）
需要我们注意的一点就是：在调用notifyObservers之前一定要先掉用setChange(),
2：新建一个观察者类，实现JDK中Observer(java.util.Observer)接口
通过上面的代码，我可以发现
1）：JDK提供的观察者接口中的update方法有二个参数，其实这二个参数满足了我们的推模式和拉模式，如果使用推模式的话，我们只需要关注arg这个参数，（如果有多个数据，我们可以封装成一个model ,或者拼成一个字符传）如果是使用拉模式，我们就需要把update方法中的Observable o 进行转换然后调用get 方法来获取需要的数据
2）：观察者与目标对象的关联，在JDK中观察者是需要维护一个目标对象的基类，如上面code中定义的 private Observable obsable; 在构造函数中将具体的目标类传入并对其赋值如上图中构造函数的code
3）：还有一个不同点就是观察者的移除，基于JDK的实现中，观察者的添加和移除是放在具体的观察者中，添加：在构造函数中调用this.obsable.addObserver(this); 删除是调用this.obsable.deleteObserver(this);
3：更改我们的测试类，并查看运行结果
5：观察者模式的适用场景
1): 在一个数据模型中，存在二个方面，其中一个方面的变化需要依赖与另一个的状态变化
2): 当一个对象的状态改变会影响和他相关联的多个对象的行为，使用观察者模式，可以通过广播的方式通知到每一个观察者
6：观察者模式的优缺点
优点：
1): 建立了一个目标对象和观察者的抽象耦合（目标对象不需要知道具体的观察者对象，只需要知道他们的统一接口）
2): 实现了动态联动，通过在目标对象和观察者中建立一套触发机制后，当目标对象一发生变动，可以及时的通知到每一个观察者
3):使用的广播机制来将消息传递给每一位观察者
缺点：
1):正是由于他的广播机制，所以可能会带来一些，不必要的更新，比如当只有某一个观察者需要更新时，目标对象会把消息广播给每一个观察者，浪费效率
2):因为目标对象在通知观察者时是一个接一个的，当其中某一个一但假死，会阻塞后面的观察者接受消息。
