设计模式之观察者模式

有些模式比如装饰器模式这种。有点类似于结构组合的东西。我希望能琢磨琢磨使用数学表达的方式去总结一下因该会更加直观。很抱歉的是观察者模式并没不能这么总结。因为观察者不是扩充方法，或者让我们更灵活的传递或者组合方法。这么想的话观察者模式就少了数学美感。

言归正传。观察者模式就是监听某一个对象的变化然后调用其他方法做出应对。是用来对应这种特殊需求的。菜鸟已经讲的很简单了。留个笔记记录一下。

假设这里有一个对象A.当A的某些或者某一个更新类方法被调用的时候我们需要调用一个（类型不确定的集合对象的方法）对象集合B通知他。

题外话（监听一个对象的改变。通常我们可能会想起。定时器监听接口同步刷新。但是这种方法真的很糟糕。最好的方式当然是主动通知，你有了变化你自己通知我。这就是消息通知的意义。mq出场）

绝大多数时候我们只考虑自己的系统，在一般情况下，我们调用类似update操作的时候，同步的再去调用另外一个update操作就好了。这里有一个相关性哈。当某一个update被调用。我们需要调用另外一个update.硬编码一个个调用就好。比如在创建用户的时候我们还需要做一堆额外的操作。或者注销账号的时候我们也要做一堆关联操作。这个例子只用来说明这种方法之间的前后依赖关系哈。

观察者模式考虑的情况更周到一点。首先就是新增消息通知我不需要修改原来代码。假如我要动态的增加观察者进来。我还要去改触发方法的代码这就不合理。综上所述呢。我们有一个类A.A的某些方法被调用的时候需要去调用一堆类（称为对象集合B）的方法。

很直接的A需要持有B,A怎么调用不同类的同一个方法呢。那就创建一个接口，这个接口姑且叫他observer.里面加一个需要同步更新的方法update().很逗的是这家伙明明就是躺平被动被调用哈哈。

于是代码就变成了

A{
List<Observer> observers=new LinkedList();

 public void attach(Observer observer){//需要被关联调用自己把把柄主动交上来
      observers.add(observer);      
   }

 public void notifyAllObservers(){//关联调用小弟门
      for (Observer observer : observers) {
         observer.update();
      }
   } 
}

于是很自然的，触发方并不关心有哪些需要被同步跟新。需要的自己实现observer接口，自己attch上门就好了。 

总结一句话就是。在某个对象的方法触发多个未知方法的时候，不再由触发方来实现。由被触发方自己实现同步更新接口，并且把自己的对象句柄添加到触发方的通知集合里面。