商业鬼才教你 观察者模式

故事线

前文说道，广军开了三家连锁，而他自己退居幕后。
有一天，他心血来潮，去到各家店铺“微服私访”，却发现有的员工消极怠工，毕竟做的时间长了，工资也涨停了，大家的激情和热度渐渐的就下去了。而且在急速扩张的过程中，也缺乏了一定的监管机制，所以，嗯，人都是有惰性的，广军如是想，也就能理解了。

但是吧，理解是一回事儿，解决问题又是一回事儿。他想用上班打卡的方式来督促员工。

“老板，我刚刚钱包在你们店里给丢了，你有没有看见？” 忽然间，广军听到前面一阵喧闹，原来是隔壁的店里面人多眼杂地方小，发生了“失窃”。
“喂，查监控啊，你们店不会连这都没有吧？”
“我那钱包里面可有五千块钱，这要找不到，可得你们来负责了！！！”

广军想：都说财不外露，你这怪谁？这店主也是倒霉，摊上这么个事儿，还不知道是不是碰瓷，没装监控这下说不清楚了。

叹了口气，广军就走了，走着走着，广军突然想起来，自己的店里好像也没有装监控啊！！！
还好，事情还没发。

又走了几步，广军又想，自己当年上大学的时候，好像那上课打卡签到也没什么用，该睡觉的依旧睡觉，该逃课的依旧逃课，反正签完到就是自由身，爱干嘛干嘛。那自己的店搞这种签到的形式主义有用吗？当然形式主义还是要搞的。

于是，广军决定，将打卡、监控、绩效考核结合在一起，形成一套完整的考核机制，打卡用来保证上班时间所有员工都在岗，监控用于检测员工是否擅离职守，以及店内是否有异常现象出现，而绩效考核就用来确定最后的员工奖金。

万恶的资本家广军。。。
当然，在买设备这件事情上他还是不含糊的，这一套设备可不便宜。

观察者模式

上边那个故事呢，如果非要说是个什么设计模式，那必须是 “观察者模式” 啦！！！

Observer 模式应该可以说是应用最多、影响最广的模式之一，因为 Observer 的一个实例 Model/View/Control（ MVC） 结构在系统开发架构设计中有着很重要的地位和意义， MVC实现了业务逻辑和表示层的解耦。

再碧如，并发模式下的进程间、线程间通信，信号量、条件变量，这些都属于“观察者模式”的范畴。
之前就业部老师跟我说：这个观察者模式一定要熟练，有一家公司的HR跟我说，他们公司就需要这样的人才，有观察者模式经验者优先考虑！！！

好，费话不多说，我们直入主题：

什么是观察者模式

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化，关注它的对象就会得到通知；这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者。

观察者模式通用类图

Subject（目标）
——目标知道它的观察者。可以有任意多个观察者观察同一个目标；
——提供注册和删除观察者对象的接口。

Observer（观察者）
——为那些在目标发生改变时需获得通知的对象定义一个更新接口。

ConcreteSubject（具体目标）
——将有关状态存入各ConcreteObserver对象；
——当它的状态发生改变时，向它的各个观察者发出通知。

ConcreteObserver（具体观察者）
——维护一个指向ConcreteSubject对象的引用；
——存储有关状态，这些状态应与目标的状态保持一致；
——实现Observer的更新接口以使自身状态与目标的状态保持一致。

小故事类图

小故事代码

以下这段代码会比较抽象，对于没有学过多线程的朋友。

那我就用伪代码，尽量简洁易懂一些的展示：

//这里是员工线程

class employee{
private:
	bool state;	
public:
	void daka(){
		sendsignal();	//发送信号：打卡，滴滴滴···
	}
	void setState(){
		state = !state;
	}
};

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
 

//这里是监控线程1，监控员工在岗状态
class watchout1{
	void watchemployee(){
		while(1){ if(!employee.state){ //这里的employee可能会是张表，所以说是伪代码。我手上有一份心跳包的检测，很适合这份场景，有需要下面评论我 contoral.employeelost();	//后台处理 }
		}
	}
};
//另一个监控线程就不写啦。	

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
 

观察者模式，建议学习：勉强能看的线程池详解，
以及心跳包处理。

栗子对应场景：
线程池：主动汇报给观察者，观察者采取相应行动
心跳包：被观察者抓到有问题，观察者采取相应行动

观察者模式的优势

观察者和被观察者之间是抽象耦合的，如此设计，不论是观察者还是被观察者，都可以独立拓展。
建立了一套触发机制。

  

 

  
1
  
2
 

观察者模式的缺点

观察者模式需要考虑一下开发和运行效率问题。

其实这都不是大问题，现在哪个项目不用多线程来跑啊，总不能因为调试困难就因噎废食吧。
注意事项

广播链问题

如果一个对象，它既是观察者，又是被观察者，那就比较复杂了，我是还没遇到那种特别变态的广播链了，简单点的单行广播链还是可以应付的（每条链都是三个对象，用”中介+观察“就可以解决）。

  

 

  
1
 

它和责任链最大的区别就是，观察者广播链在传递的过程中，是可以被改变的，而且传播方向千变万化。

文章来源: lion-wu.blog.csdn.net，作者：看，未来，版权归原作者所有，如需转载，请联系作者。

原文链接：lion-wu.blog.csdn.net/article/details/108734017