设计模式之观察者模式——"订不订奶您随意"

名称	观察者模式
目的	解决类之间一对多关系
方法	在“一”中增加对“多”的管理

设计场景：

1、牛奶厂要向A小区开展每天免费送奶的业务了，可是到底有多少人想要定牛奶，有些人这个月定了，下个月又退订了，怎么办？

2、为解决这个问题，牛奶厂在A小区雇了一名小奶童负责整个小区的所有业务

我就是那个小奶童！！！

当然，还有一堆嗷嗷待哺的“小区住户”

        我们要喝奶！！！

3、代码结构设计如下：

 

于是，在A小区，现在有A住户、B住户均为订奶者，而A小区奶童也正式接管了一个奶童的所有职责。

有了小奶童，牛奶厂每天只管把牛奶送到A小区就好。小奶童通过自身的    送奶（）方法，给小区内所有订奶的订奶者送奶，并调用他们的收奶（）方法，确保他们都收到了奶，这样小区住户们收到奶后，就可以尽情的喝奶了。牛奶不错，现在要增加一个定奶者，仅需要调用奶童的增加一个订奶者（）方法，再下次送奶的时候，奶童遍历了所有订奶者，新订户也有奶喝了。有家住户要搬家了，取消取消订奶，调用奶童的删去一个订奶者（）方法，再下次送奶的时候，便不会再给他送奶了，当然，也不收他家的钱咯~

       

摘抄GOF的定义如下：

Oberver: Define a on-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

观察者模式：定义了对象之间的一对多以来，这样一来，当一个对象改变状态时，他的所有依赖者都会收到通知并自动更新。

Java有多种观察者模式的实现，包括了通用的Java.util.Obervable

观察者模式的应用场景：

1、  对一个对象状态的更新，需要其他对象同步更新，而且其他对象的数量动态可变。

2、  对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。

观察者模式的优点：

1、  Subject和Observer之间是松偶合的，分别可以各自独立改变。

2、  Subject在发送广播通知的时候，无须指定具体的Observer，Observer可以自己决定是否要订阅Subject的通知。

3、  遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

观察者模式的缺陷：

1、  松偶合导致代码关系不明显，有时可能难以理解。(废话)

2、  如果一个Subject被大量Observer订阅的话，在广播通知的时候可能会有效率问题。（毕竟只是简单的遍历）

注：

1、以上内容虽参考了多位大牛和经典，然鄙猿不才，理解难免有不到位之处，欢迎看到本文的朋友多多提意见，多谢。

2、有些人说设计模式不实用，但静心思考，设计模式确是编程的艺术，一个个模式间流露了多少思维的灵动和严密。程序猿的生活不是枯燥的代码堆积。共勉。

参考及感谢

书籍：

《设计模式——可复用面向对象软件的基础》

《Head First Design Patterns》

博文：

http://www.cnblogs.com/justinw/archive/2007/05/02/734522.html

视频：

尚学堂马士兵老师的设计模式视频