#每天一种设计模式# 观察者模式

 

 

系统常常会出现这种情况：

每一个部分需要知道整体的状态。比如Excel中，当你修改了一个单元格的值，可能横列的sum需要改变，纵列的sum需要改变，根据这个单元格做的图需要改变，是否被修改的按钮需要激活... 如果没有一种很好的处理方式，导致的结果将是系统 highly integrated。

 

仔细分析，比如Excel的单元格，我们可以抽象出单元格是a source of news ，而其他部门是 receiver，接受单元格的改动的通知，然后进行自己的处理。

比如，单元格修改之后，通知计算总和的类来做相应的处理。

 

 

class Excel
         attr_reader :cell
         def initialize(value,sum)
               @cell = value
               @sum = sum
         end
         def cell=(value)
               @cell = value
               @sum.update
         end
end

class Sum
         def update
               puts "Got Excel Cell Changed"
         end
end

sum = Sum.new
excel = Excel.new(10,sum)
excel.cell = 11

 

在这个例子上，这一切完全ok。但是唯一的缺点是，Excel和Sum之间是硬连接(hard-wired)。比如，当cell改变的时候，除了Sum类，Graph类也需要得到通知，在这个例子上，我们只能修改cell=(value)这个函数。改动量的确不是很大，不过，Excel类并没有真的改变，只是因为增加一个receiver，却需要修改source所在的类。这总是有些不太合理吧。

 

      ok,让我们把事情做的彻底一点。

 

 

class Excel 
         attr_reader :cell
         def initialize(value)
               @cell = value
               @observers = []
          end
          def cell=(value)
                @cell = value
                notify_observers
           end
           def notify_observers
                 @observers.each do |observer|
                        observer.update
                  end
           end
           def add_observer(observer)
                  @observers << observer
           end
           def delete_observer(observer)
                   @observers.delete(observer)
            end
end

class Sum
         def update
               puts "Got Excel Cell Changed"
         end
end

sum = Sum.new
excel = Excel.new(10)
excel.add_observer(sum)
excel.cell = 11

      通过这种方式，source不需要知道有多少receiver对它感兴趣，而增加一个新的receiver也只需要调用add_observer方法即可。

      这样Observer模式的结构就已经展现在眼前了。

 

GoF把source叫为subject class，而receiver较为observers.

 

the Ruby standard library 提供了一个Observable module让我们可以轻松实现Observer模式。