意图:
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
别名:
依赖(Dependents),发布—订阅(Publish—Subscribe)
动机:
将一个系统分割成一系列相互协作的类有一个常见的副作用:需要维护对象间的一致性。我们不希望未来维护一致性而使各类紧密耦合,因为这样降低了它们 的可重用性。
适用性:
在一下任一情况下可以使用观察者模式:
当一个抽象模型有两个方面,其中一个方面依赖于另外一个方面。将这二者封装在独立的对象中以使它们可以各自独立的改变和复用。
当一个对象的改变需要同时改变其它对象,而不知道具体有多少对象有待改变。
当一个对象必须通知其它对象,而它又不能假定其它对象是谁。换言之,你不希望这些对象之间是紧密耦合的。
参与者:
Subject(目标)
——目标知道它的观察者。可以有任意多个观察者观察同一个目标。
——提供注册和删除观察者对象的接口。
Observer(观察者)
——为那些在目标发生改变时需获得通知的对象定义一个更新接口。
ConcreteSubject(具体目标)
——将有关状态存入各ConcreteSubject对象。
——当它的状态发生改变时,向它的各个观察者发出通知。
ConcreteObserver(具体观察者)
——维护一个指向ConcreteSubject对象的引用
——存储有关状态,这些状态应与目标状态保持一致。
——实现Observer的更新接口以使自身状态与目标的状态保持一致。
以上摘自《设计模式》。
下面谈谈之前的两段代码经验:
1.一个小型的C/S程序。服务器端负责数据管理,向客户端广播当前数据的版本消息,同时负责接收客户端数据下载请求与数据目录请求。在该项目中,Subject只有一个,通过IP地址可来选择性的收发消息。Observer可以得到来自Subject广播的消息,也可以主动获取请求。即,两方的通信既可以是Observer激活,也可由Subject激活。
2. 一个界面编辑程序。在界面编辑GIS(地理信息系统)数据坐标时,以Delegate(委托)方式来调用外部插件实现的操作准许函数。在该项目中,Subject是GIS数据,Observer是外部插件。不同的是Observer同时具有控制作用,如果Observer发现当前数据操作违法,则返回操作false,从而拒绝了Subject中数据的修改。想象到了《Fringe》中的Observer,2015年(好像是)后开始控制人类……。由此看,Observer模式不一定局限于“Observer”。
个人之间,如有纰漏,欢迎批评指正。