观察者设计模式——你在看什么，你在看什么？..最近在做一个在线培训的项目，开发起来费了不少功夫。这时候产品经理笑着跑过来跟我说，那又怎样，改需求，网训学员支持去掉，去掉是为了扣掉相应的学分。我冷冷看了她一眼，心想你若是拉拉长得好看，等天王来了我就不用讨论了。找到负责学分的同事A，添加了扣学分的接口。我把学生去掉后，调用他的接口。折腾了半天，大功告成。第二天，产品经理笑着跑过来说，嗯，我昨天跟你说的需求，不仅要扣学分，还要记缺席。我的妈，你昨天怎么不一起说呢，你昨天就没想好吗，嘿嘿。只好又找了正在考勤的同事B，加了个缺勤接口。我把学生去掉后，调用了他的接口。工作了半天，就OK了。第三天，产品经理又跑过来，笑着说，嗯，那个昨天还有。..怒就是怒，需求总要被满足，这个基本的职业素养还是有的。其实想想，这是一个典型的业务场景。当一个对象的改变需要同时改变其他对象，并且不知道需要改变多少个对象时，观察者模式是更好的选择。观察者模式定义了对象之间一对多的依赖关系，这样每当一个对象改变状态时，所有依赖它的对象都会得到通知并自动更新。也叫发布/订阅模式Publish/Subscribe，属于行为型设计模式的一类。在上面的业务场景中，移除学生是行为的发起者，同事A和B是行为的观察者。当然，你可以根据自己的业务场景添加同事C、D、E等。当有删除学生的动作时，A执行相应的扣学分操作，B执行相应的标记缺席操作，C执行相应的操作。..接下来我们用代码来实现产品经理小姐姐的异常需求。1.定义行为触发器类首先定义行为触发器类。这个类有一个移除学生行为的方法。当我们删除学生时调用此方法。然后就可以定义它的实现类，重写成员更改方法。该方法的实现逻辑无非是通知与其相关的对象：我要移除该学生。那么谁可以收到通知呢？2、添加观察者这里的观察者就是上面场景中的同事A和B，他们都想收到学生变动的通知。这里的实现非常简单。你要接收通知，注册你的信息，我会保存在这里。需要通知时，我会把所有注册人的信息拿出来，一一通知；如果您不想收到通知是的，取消注册信息，我会从存储中删除您的信息，这样当我再次通知您时，我不会通知您。回到代码，我们使用一个列表来存储所有注册者的信息。列表集合是一个接口，需要所有的观察者都实现这个接口才能注册。接口中会有指定的方法，所有的观察者也必须实现这个方法。这个方法就是每个观察者在收到通知时都会进行的操作。对应上面的场景，同事A更新学分，同事B标记缺席等。这个接口可以自己定义，java也提供了Observer工具类供大家使用。代码如下：3.观察者定义这里，观察者的定义比较简单。实现Observer接口，重写update方法，在类初始化的时候注册自己的信息成为观察者，就OK了。4、在测试中可以看到，我们调用了studentchange方法后，同事A和同事B都收到了通知，并进行了相应的操作。
