在软件工程中,有一条重要的原则就是:高内聚低耦合。这是评定软件的设计好坏的一个标准。所谓高内聚,指的是一个模块内各个元素关联紧密,共同完成一个核心业务。低耦合,指的是各个模块之间依赖松散。创建低耦合模块,这一过程也成为解耦。
观察者模式正是低耦合的软件设计,也称为发布(publish )-订阅(Subscribe)模式。什么是观察者模式?举个栗子:王二小在山上放牛,突然他看见了鬼子到了村外,于是他把山上的烽火台点燃了。村民看见狼烟,都把自家的粮食啥的藏了起来;花姑娘看见狼烟,赶紧换上了庄稼汉的着装;民兵把村口的地雷挂上了弦,扛上枪埋伏在村口;政委组织村民撤退;树上的乌鸦继续敷蛋。这就是生活中的观察者模式,王二小负责点着烽火台后,就没他事了,村里人看见信号后,各自做出了响应。此案例用例图如下:
从用例图可以看出,每一个参与者相互独立,各自完成独立业务,即使他们都同时响应‘狼烟’,彼此互不影响。
那么在Web项目中如何应用观察者模式呢?在直播系统中,众多信息依赖于socket实时通信,在传统做法中,socket消息推送回来后,判断消息类型,之后去调用响应的业务处理方法。代码类似如下: 这样的做法负责处理socket消息模板将依赖所有处理socket的A,B。。。其中的switch case将不断堆积。每个业务,比如A弃用了,我们在删除A文件的同时,还要在socket文件进行对应的操作,这样耦合程度就很高了。在业务庞大起来的时候还是会带来一定的维护成本。
在这个情况下,其实我们可以采用广播机制,广播机制就是观察者模式的一种体现。socket模块在接收到推送的消息时,发送一条广播,将socket消息类型和数据广播出去。每个业务模块监听这个广播消息,然后完成各自的业务处理。sochet模块和业务模块达到了解耦的效果,更易于维护,性能更加稳定。