请选择一种我们课程中介绍的设计模式，用您熟悉的编程语言提供一个典型的应用范例，并分析其代码结构特性。完成一篇研究报告，具体要求如下：

 引用关键代码（引用代码是为解释说明服务的，不要贴对解释问题无关的代码）解释该设计模式在该应用场景中的适用性；

 引入该设计模式后对系统架构和代码结构带来了哪些好处；

 解释其中用到的多态机制；

 说明模块抽象封装的方法；

 分析各个模块的内聚度和模块之间的耦合度；

 提供该应用范例完整的源代码包括构建部署的操作过程，建议以github版本库URL的方式提供源代码，其中README.md中说明构建部署的操作过程。

观察者模式

1、观察者模式的定义：

观察者模式（又被称为发布-订阅（Publish/Subscribe）模式，属于行为型模式的一种，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。

2、观察者模式的结构：

观察者模式的结构中主要有以下四个构成角色：

（1）Subject：抽象主题，抽象主题提供一个接口，可以增加和删除观察者对象。

（2）ConcreteSubject：具体主题，他把所有观察者对象保存在一个集合里，可以有任意数量的观察者。该角色还将有关状态存入具体观察者对象，在具体主题的内部状态发生改变时，给所有注册过的观察者发送通知。

（3）Observer：抽象观察者，是观察者的抽象类，它定义了一个更新接口，使得在得到主题更改通知时更新自己。

（4）ConcrereObserver：具体观察者，实现抽象观察者定义的更新接口，以便在得到主题更改通知时更新自身的状态。

从类图的角度来看，四个角色的关系如下：

3、具体案例分析：

现在有这样一种情况：气象局要求设计一套系统，这个系统有两个公告显示牌，每当后台的天气数据发生更新，两个公告牌的显示内容也要跟着变化。一个公告牌显示的是当前的天气，另一个是显示未来几天的天气。

按照观察者模式进行设计，和设计模式有关的代码如下：

         * 注册观察者
      observer
         * 移除观察者
      observer
         * 通知观察者

这是主题接口Subject，是一个抽象接口类，是对我们的被观察者的抽象，具体类的实现会重写其中的方法。

这是观察者接口，它定义了一个更新接口，使得在得到主题更改通知时更新自己。

公告牌用于显示的公共接口。

      observers
      temperature
      humidity
      pressure
      forecastTemperatures
        observers   
       observer 
        observersobserver
       observer 
        observersobserver
          observer  observers 
            observer
       temperature  humidity  pressure  forecastTemperatures 
        temperature  temperature
        humidity  humidity
        pressure  pressure
        forecastTemperatures  forecastTemperatures
         temperature
         humidity
         pressure
         forecastTemperatures

以上是WeatherData类，它继承了抽象接口Subjects，在这个类中，保存了Observer接口的对象列表。WeatherData相当于一个具体主题角色，它重写了注册、删除观察者，也因为它用观察者列表保存了观察者，所以可以在天气数据发送变化时通知所有观察者。

      weatherData
      temperature
      humidity
      pressure
      weatherData 
        weatherData  weatherData
        weatherData
        out  temperature  
        out  humidity
        out  pressure
        temperature  weatherData
        humidity  weatherData
        pressure  weatherData

以上是显示当前天气的公告牌，它是一个具体类，继承了两个公共接口：观察者Observer和显示信息DisplayElement。在这个类中，重写了display和update函数，当被观察者WeatherData发生变化时，这个公告牌作为观察者，被观察者WeatherData将会遍历到这个观察者对象，调用其中的两个函数，完成公告牌的更新。

      weatherData
      temperature
      humidity
      pressure
      weatherData 
        weatherData  weatherData
        weatherData
        out  temperature  
        out  humidity
        out  pressure
        temperature  weatherData
        humidity  weatherData
        pressure  weatherData

和显示当前天气的公告牌类似，这是一个显示未来天气的公告牌，这个类和当前天气公告牌类是并列的逻辑关系，都是天气数据的观察者。其中的display和update函数的实现与当前天气公告牌类中的实现不同，体现了角色相同，但功能不同。

        args 
         weatherData   
         currentConditionsDisplay   weatherData
         forecastDisplay   weatherData
         forecastTemperatures   
        forecastTemperatures
        forecastTemperatures
        forecastTemperatures
        forecastTemperatures
        forecastTemperatures
        forecastTemperatures
        forecastTemperatures
        weatherData   forecastTemperatures

最后，这就是天气数据发生一次变化后的场景模拟，两个公告牌类在创建时就”订阅“或者”注册“了天气数据，天气数据类相当于拥有一个”注册表“，一旦天气数据成员变量发生变化，就notify所有注册的观察者。所以程序的结果会打印出最新更新的天气内容。

4、引入该设计模式后对系统架构和代码结构带来了哪些好处？

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

具体来说，在上例中，好处在于，不需要在天气数据类中一开始就确定要更新的公告牌，因为考虑到可扩展性，后期可能会有很多很多的公告牌需要更新，采用观察者模式，就避免了程序的修改。

5、解释其中用到的多态机制，说明模块抽象封装的方法

这里多态机制主要体现在抽象接口的使用，在设计观察者时，先使用了一个观察者的抽象接口类Observer，这样在天气数据类中，不论是什么样的具体的观察者，都被看做是抽象观察者Observer，调用抽象观察者的update函数，再根据不同的具体观察者调用不同的update实现。这样的抽象非常重要，保证了被观察者中处理观察者方法上的一致性。

6、分析各个模块的内聚度和模块之间的耦合度

观察者模式将观察者和主题（被观察者）彻底解耦，主题只知道观察者实现了某一接口（也就是Observer接口）。并不需要观察者的具体类是谁、做了些什么或者其他任何细节。任何时候我们都可以增加新的观察者。因为主题唯一依赖的东西是一个实现了Observer接口的对象列表。总而言之，具体观察者与被观察者没有耦合，抽象观察者与被观察者有一定耦合关系，但因为抽象类自身太简单，没有实现，所以也是很低的耦合。

  github地址：https://github.com/BaronZ88/DesignPatterns