最近比较烦，比较烦，比较烦，产品经理总把我为难。。。,最近在做一个线上培训的项目，费了九牛二虎之力开发完了，这时产品经理笑嘻嘻的跑过来告诉我，那啥，改个需求，线上培训的学员支持移除，移除了要把获取到的相应学分扣除掉。我冷冷的看了她一眼，心想要不是看你是个女同志并且长得还行，天王老子来了也没得商量。找到负责学分的同事A，加了一个扣除学分的接口，我这边移除学员后调用他的接口，忙活半天，算是搞定了。,第二天，产品经理又笑嘻嘻的跑过来说，那啥，昨天跟你说的那个需求，不仅要扣除学分，还要标记缺勤。我尼玛，你昨天咋不一起说，这不昨天没想起来嘛，嘿嘿。没办法，又找到考勤的同事B，加了一个标记缺勤的接口，我这边移除学员后调用他的接口，忙活半天，也算OK了。,第三天，产品经理又笑嘻嘻的跑过来说，那啥，昨天那个还得。。。,生气归生气，需求总还是要实现的，这点基本的职业素养还是有的。,其实想一想，这算是一个比较典型的业务场景，当一个对象的改变需要同时改变其它对象，且它不知道具体有多少对象有待改变的时候，观察者模式，是一个比较好的选择。,观察者模式，定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新，也叫做发布订阅模式Publish/Subscribe，属于行为型设计模式的一种。,上述的业务场景，移除学员是一个行为的发起者，同事A和B是行为的观察者，当然可以根据你的业务场景增加同事C、D、E等等。当有移除学员的动作发生的时候，A进行相应的扣除学分操作，B进行相应的标记缺勤操作，C进行。。。,下面我们用代码来实现产品经理小姐姐的变态需求。,首先定义行为触发的类，这个类中有一个行为移除学员的方法，当我们移除学员的时候调用这个方法。,然后可以定义它的实现类，重写成员变更的方法，这个方法的实现逻辑无非就是通知跟它有关的对象：我要移除学员了。,那谁能收到通知呢?,这里的观察者就是上述场景中的同事A与同事B，他们都想要收到学员变更的通知。这里的实现很简单，你要接收通知，把你的信息注册过来，我这边存储一下，需要通知的时候，我把所有注册者的信息拿出来，一一的进行通知;如果你不想接收通知了，注销一下注册信息，我把你的信息从存储中删掉，这样再通知的时候，就不会通知你了。,回到代码中，我们用一个list进行存储所有注册者的信息，list集合中是一个接口，要求所有观察者都必须实现这个接口才能注册进来，接口中会有指定的方法，所有观察者也必须实现这个方法，这个方法就是各个观察者在收到通知时要进行的操作，对应上述场景中，A同事更新学分，B同事标记缺勤等。这个接口可以自己定义，java也提供了Observer工具类供大家使用。代码如下：,这里观察者的定义就比较简单了，实现Observer接口，重写update方法，在类初始化的时候把自己的信息注册进去成为观察者，就OK了。,可以看到我们调用学员变更方法后，同事A和同事B都收到了通知，并执行了相应的操作。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
