观察者模式——行为型设计模式之五
最后更新于:2022-04-01 09:30:17
## 一、观察者模式
这个模式还有另一个名字发布——订阅模式。我觉得这个模式跟适合点。
定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。
这个模式跟我们的博客委员会的职能很相像哦!
每个月我们都要对博客进行一次检查。当管理员要结果时,博客委员会组长就得把各自组的博客结果发给管理员。
看一下我们的博客委员会的成立过程:
开始:当每个月底时,管理员会像考勤人员要统计结果。
那管理员怎么通知他们呢?
一个一个通知他们,让他们把结果发给管理员。这样,五个人就需要通知五遍,N个人就要通知N遍吗?显然不行。
建立一个飞信群——博客管理,把相关人员加入,直接在群里发一个通知,被加入群的人就可以收到通知,然后把整理结果发送。
接着:由于各种原因,现在管理人员需要2名,又增加一名监督人员,负责对考勤人员监督;照葫芦画瓢,我们可以让新增的管理人员模仿老管理人员,也建个群,也把这些人加进去;同时,还需要在群里增加监督人员。到月底时,管理员发送通知,考勤组和监督组分别执各自任务。
这样做目的达到!就是有点小问题,管理员得交给新管理员怎么做。假如急需要结果,管理员不在,怎么办,这样是不是很不灵活;要是再多一个小组呢?这个小组在接收到群消息时,应该做什么。这时候我们就需要考虑建立一个抽象模板,让每一个新加的管理员都按照模板的章程来办事,就不需要向非得等管理员了;给各个小组建立一个头目,让这个头目来对各个小组进行管理,只要把结果发给管理员即可,这就是博客委员会了。
怎么样?是不是发现,原来我们一直都在用观察者模式办事呢?只是不知道它还有一个这样的学名。
通知,接收,为了让各个对象耦合度降低,我们都抽象出一个类。
看一下类图,看看是不是这回事呢?
## 二、类图
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-02-18_56c5ce72e45a2.png)