1. 简介

　　关于observer模式的细节可以参考讲述设计模式的书籍。其类图如下所示：

　　图1：observer模式类图

　　本例主要讲述如何在项目中应用observer模式以满足客户的需求，客户需求如下：

　　1) 每个待审核的条目需要多人组成的小组(审核小组)中的所有人签名确认才算审核通过。

　　2) 审核小组成员签名是在专门的会议室的机器上审核，所有成员每人一台机器坐在一起讨论，讨论完毕一起签名确认。

　　3) 定义会议室中某几台机器为审核小组讨论所要使用的机器，其中一台定义为主控机，其他为从控机，主控机有且只有一台。

　　4) 在主控机或从控机上登录的用户均为审核小组成员。

　　5) 未被主控机器访问的条目不视为进入审核小组审核状态；已被主控机访问的条目视为进入审核状态，并记录当前在特定机器上登录的用户为该条目的审核小组成员。

　　6) 中途若有用户在特定的机器上登录进入，则该用户也成为当时进入审核小组讨论状态但未审结的条目所对应的审核小组中的成员。

　　7) 若中途有用户退出应用系统，如存在已进入小组讨论状态但该用户未签名的条目，则在该用户退出前提示该用户有尚未签名的条目，确认是否退出，但不强制用户必须签名方可退出。该成员退出系统后，将不属于当时已进入审核小组讨论状态条目的审核小组成员，不需要该用户签名确认。

　　
　　从需求我们可以看出，审核小组是一个虚拟的概念，每个待审核条目的审核小组成员是随着用户登录和退出系统动态变化的。我们不妨回顾一下Observer的意图：在对象之间定义一种一对多的依赖关系，这样当一个对象的状态改变时，所有依赖于它的对象都将得到通知并自动更新。在本例中，我们在“用户登录/退出”和“把用户加入到审核小组/从审核小组中删除”以及“把用户加入登录用户列表/把用户从登录用户列表中删除”之间建立依赖关系，应用第二种方式的observer模式监听用户的登录和退出事件从而触发相应的动作。