(转载请注明：http://zhutty.cnblogs.com, 交流请加群：164858883)

　　在软件工程中，有一条重要的原则就是：高内聚低耦合。这是评定软件的设计好坏的一个标准。所谓高内聚，指的是一个模块内各个元素关联紧密，共同完成一个核心业务。低耦合，指的是各个模块之间依赖松散。创建低耦合模块，这一过程也成为解耦。

　　观察者模式正是低耦合的软件设计，也称为发布（publish ）-订阅（Subscribe）模式。什么是观察者模式？举个栗子：王二小在山上放牛，突然他看见了鬼子到了村外，于是他把山上的烽火台点燃了。村民看见狼烟，都把自家的粮食啥的藏了起来；花姑娘看见狼烟，赶紧换上了庄稼汉的着装；民兵把村口的地雷挂上了弦，扛上枪埋伏在村口；政委组织村民撤退；树上的乌鸦继续敷蛋。这就是生活中的观察者模式，王二小负责点着烽火台后，就没他事了，村里人看见信号后，各自做出了响应。此案例用例图如下：

　　从用例图可以看出，每一个参与者相互独立，各自完成独立业务，即使他们都同时响应‘狼烟’，彼此互不影响。

　　那么在Web项目中如何应用观察者模式呢？在直播系统中，众多信息依赖于socket实时通信，在传统做法中，socket消息推送回来后，判断消息类型，之后去调用响应的业务处理方法。代码类似如下：　　这样的做法负责处理socket消息模板将依赖所有处理socket的A,B。。。其中的switch case将不断堆积。每个业务，比如A弃用了，我们在删除A文件的同时，还要在socket文件进行对应的操作，这样耦合程度就很高了。在业务庞大起来的时候还是会带来一定的维护成本。

　　在这个情况下，其实我们可以采用广播机制，广播机制就是观察者模式的一种体现。socket模块在接收到推送的消息时，发送一条广播，将socket消息类型和数据广播出去。每个业务模块监听这个广播消息，然后完成各自的业务处理。sochet模块和业务模块达到了解耦的效果，更易于维护，性能更加稳定。

项目代码：https://github.com/SuunZhu/broadcastMsg 请给颗Star