1.概述

    一些面向对象的编程方式，提供了一种构建对象间复杂网络互连的能力。当对象们连接在一起时，
它们就可以相互提供服务和信息。
    通常来说，当某个对象的状态发生改变时，你仍然需要对象之间能互相通信。但是出于各种原因，
你也许并不愿意因为代码环境的改变而对代码做大的修改。也许，你只想根据你的具体应用环境而改进通信代码。
或者，你只想简单的重新构造通信代码来避免类和类之间的相互依赖与相互从属。

demo地址，欢迎star

2.问题

   当一个对象的状态发生改变时，你如何通知其他对象？是否需要一个动态方案――一个就像允许脚本的执行一样，
允许自由连接的方案？

3.解决方案

    观测模式：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 
所有依赖于它的对象都得到通知并被自动更新。

    观测模式允许一个对象关注其他对象的状态，并且，观测模式还为被观测者提供了一种观测结构，
或者说是一个主体和一个客体。主体，也就是被观测者，可以用来联系所有的观测它的观测者。
客体，也就是观测者，用来接受主体状态的改变 观测就是一个可被观测的类（也就是主题）与一个或多个
观测它的类（也就是客体）的协作。不论什么时候，当被观测对象的状态变化时，所有注册过的观测者都会得到通知。
观测模式将被观测者（主体）从观测者（客体）种分离出来。这样，每个观测者都可以根据主体的变化
分别采取各自的操作。（观测模式和Publish/Subscribe模式一样，也是一种有效描述对象间相互作用的模式。）
观测模式灵活而且功能强大。对于被观测者来说，那些查询哪些类需要自己的状态信息和每次使用那些状态信息的
额外资源开销已经不存在了。另外，一个观测者可以在任何合适的时候进行注册和取消注册。你也可以定义多个具体的
观测类，以便在实际应用中执行不同的操作。
    将一个系统分割成一系列相互协作的类有一个常见的副作用：
需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，因为这样降低了它们的可重用性。

4.适用性

在以下任一情况下可以使用观察者模式:
• 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
• 当对一个对象的改变需要同时改变其它对象 , 而不知道具体有多少对象有待改变。
• 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之 , 你不希望这些对象是紧密耦合的。

5.结构

观察者模式.jpg

6.模式的组成

    观察者模式包含如下角色：
    `目标（Subject）`: 目标知道它的观察者。可以有任意多个观察者观察同一个目标。 提供注册和删除观察者对象的接口。
    `具体目标（ConcreteSubject）`: 将有关状态存入各ConcreteObserver对象。
    `观察者(Observer): `为那些在目标发生改变时需获得通知的对象定义一个更新接口。
当它的状态发生改变时, 向它的各个观察者发出通知。
    `具体观察者(ConcreteObserver):` 维护一个指向ConcreteSubject对象的引用。存储有关状态，
这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。

7.效果

    Observer模式允许你独立的改变目标和观察者。你可以单独复用目标对象而无需同时复用其观察者, 反之亦然。
它也使你可以在不改动目标和其他的观察者的前提下增加观察者。
    下面是观察者模式其它一些优点:
    1 )`观察者模式可以实现表示层和数据逻辑层的分离,并定义了稳定的消息更新传递机制，抽象了更新接口，
使得可以有各种各样不同的表示层作为具体观察者角色。`
    2 )`在观察目标和观察者之间建立一个抽象的耦合` ：一个主题目标所知道的仅仅是它有一系列观察者 , 
每个都符合抽象的Observer类的简单接口。目标不知道任何一个观察者属于哪一个具体的类。
这样目标和观察者之间的耦合是抽象的和最小的。因为目标和观察者不是紧密耦合的, 它们可以属于一个系统中的
不同抽象层次。一个处于较低层次的目标对象可与一个处于较高层次的观察者通信并通知它 ,
 这样就保持了系统层次的完整。如果目标和观察者混在一块 , 那么得到的对象要么横贯两个层次 (违反了层次性),
 要么必须放在这两层的某一层中(这可能会损害层次抽象)。
    3) `支持广播通信 :`不像通常的请求, 目标发送的通知不需指定它的接收者。通知被自动广播给所有已向该目标对象登记的有关对象。
目标对象并不关心到底有多少对象对自己感兴趣 ;它唯一的责任就是通知它的各观察者。这给了你在任何时刻增加和删除观察者的自由。
处理还是忽略一个通知取决于观察者。
    4) `观察者模式符合“开闭原则”的要求。`
    观察者模式的缺点
    1) `如果一个观察目标对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。`
    2) `如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。`
    3) `观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。`
    4)  `意外的更新 因为一个观察者并不知道其它观察者的存在 , 它可能对改变目标的最终代价一无所知。`
在目标上一个看似无害的的操作可能会引起一系列对观察者以及依赖于这些观察者的那些对象的更新。此外 , 
如果依赖准则的定义或维护不当，常常会引起错误的更新 , 这种错误通常很难捕捉。
    简单的更新协议不提供具体细节说明目标中什么被改变了 , 这就使得上述问题更加严重。
如果没有其他协议帮助观察者发现什么发生了改变，它们可能会被迫尽力减少改变。

demo地址，欢迎star

8.Swift代码实现

Subject协议

//可观察对象协议
protocol SubjectProtocol {
    func registerObserver(observer: Observer)
    func removeObserver(observer: Observer)
    func notifyObservers()
}

可观察对象

class WeatherData: SubjectProtocol {

    private var temperature: Float = 0.0
    private var humidity: Float = 0.0
    private var pressure: Float = 0.0
    //包含所有遵守`ObserverProtocol`的对象
    var observers = [Observer]()

    //获取数据就会触发
    func measurementsChanged() {
        notifyObservers()
    }

    //模拟数据获取的过程
    func setMeasurements(temperature: Float, humidity: Float, pressure: Float) {
        self.temperature = temperature
        self.humidity = humidity
        self.pressure = pressure
        measurementsChanged()
    }

    //MARK: - SubjectProtocol
    func registerObserver(observer: Observer) {
        if !observers.contains(observer) {
            observers.append(observer)
        }
    }

    func removeObserver(observer: Observer) {
        observers = observers.filter{ $0 != observer}
    }

    func notifyObservers() {
        observers.forEach{ $0.update(temperature: temperature, humidity: humidity, pressure: pressure)}
    }
}

观察者接口

//观察者抽象类
//这里没有协议而是用了一个基于OC的类，是因为swift的类和协议，如果被放到数组中，不能用数组来判等（contains）
class Observer: NSObject {

    //此方法不利于扩展
    func update(temperature: Float, humidity: Float, pressure: Float) {}

    //此方法有更好的扩展性
    func update(observer: Observer, arg: Any?) {}
}
//display协议
protocol DisplaymentProtocol {
    func display()
}

观察者

class ThirdPartyDisplay: Observer, DisplaymentProtocol {

    var subject: SubjectProtocol?
    private var temperature: Float = 0.0
    private var humidity: Float = 0.0

    //这里捕获了Subject的变量，这是为了以后可能取消注册，有相应的变量就可以取消注册
    init(subject: SubjectProtocol) {
        self.subject = subject
        super.init()
        //内部主动注册观察者
        self.subject?.registerObserver(observer: self)
    }

    func removeFromSubject() {
        weatherData.removeObserver(observer: self)
    }
    
    //MARK:- ObserverProtocol
    override func update(observer: Observer, arg: Any?) {
        guard let dict = arg as? [String: Any] else { print("解析错误");  return }
        if let temperature = dict["temperature"] as? Float {
            self.temperature = temperature
        }
        if let humidity = dict["humidity"] as? Float {
            self.humidity = humidity
        }
        display()
    }

    //MARK:- DisplaymentProtocol
    func display() {
        print("Current conditions: ThirdPartyDisplay--temperature:\(temperature)--humidity:\(humidity)")
    }
}

实现

let weatherData2 = WeatherData2()
let thirdPartyDisplay = ThirdPartyDisplay(subject: weatherData2)
weatherData2.setMeasurements(temperature: 10, humidity: 10, pressure: 38.4)

9.总结

HeadFirst观察者模式使用的设计原则

• 封装变化-找出应用中需要变化的地方，将他们独立出来，不要和不需要变化的代码混合到一块
• 针对接口编程而不是针对实现编程-针对接口编程实际上就是针对超类型编程，其关键在于多态，利用多态就可以实现超类型编程，也就是根据实现情况来执行具体的行为，而不是绑定在超类型的行为上。通俗一点来说，就是声明一个变量，这个变量的类型就是超类型（超类型通过是一个抽象类或一个接口，在swift中接口就是协议,不过和java的接口相比，swift协议可以有默认实现),只要具体实现此超类型的对象都可以直接赋值给上面的变量。也就是说不用关心执行具体的对象类型。
• 为交互对象之间的松耦合设计而努力

HeadFirst观察者模式:

• 在对象之间定义一对多的依赖关系，这样当一个对象改变状态，依赖它的对象就可以收到通知，并自动更新
  demo地址，欢迎star