关于 观察者模式

      前几天在书上看了关于设计模式中“观察者模式”的讲解，刚好公司有一个新的任务，就是为公司的招聘网站写一个定时向企业用户或个人用户发邮件（内容分别为简历信息和职位信息）的功能。做程序也有半年多了，觉得自己有进步的其中一点就是，不再是拿到功能就马上动手写代码，而是先去分析完成功能要的步骤。话说回来，俗话说的好，学以致用，于是我就花了点时间去想这“观察者模式”和我现在要写的东西有没有联系，其实我心理想着：“就算没联系我也要把它联起来，体验一下“观察者模式”。嘻嘻...”，最后还真把它们联系起来了，但不知道其中有多少是真正从这“观察者模式”中领悟出来的。

     php中有为“观察者模式”设计好的接口，分别是：

interface SplSubject { public function attach(SplObserver $observer); public function detach(SplObserver $observer); public function notify(); } interface SplObserver { public function update(SplSubject $subject); }

再来看看完成我公司的需求的步骤：

      首先要从数据库中拿出筛选后的数据（筛选这个步骤一开始我还不确定是否用mysql就能完成，可能要借助php，所以设计接口时有为此做保留），再用这些数据去查数据库，从返回的结果中做一些逻辑处理，最后将处理后的数据通过email发送出去。

根据上面的步骤，我把要发送的“简历信息”和“职位信息” 当做两个 observer，把要发送email的这个动作当成是它们要监听subject的动作，于是得出了下面的接口方案：（由于关系到公司方面的问题，下面的代码只是写出了大体的设计思想）

// interface ISubject { public function attach(IObserver $observer); public function detach(IObserver $observer); public function notify(); } /** * 为“简历信息”和"职位信息"设计的接口 */ interface IObserver { //从数据库中拿数据之前，可能还需要更新一下数据库 public function update(); //从数据库中拿出数据 public function getMysqlValues(); //过滤从数据库中拿出的数据 public function matchValues(); //根据拿出的数据去数据库中查找数据 public function getSearchValues(); //将找到的数据发送出去 public function sendEmail(); } class SendSubject implements ISubject { private $_observers = array(); public function attach(IObserver $observer) { $this->_observers[] = $observer; } public function detach(IObserver $observer) { if ($key = array_search($observer, $this->_observers, true)) { unset($this->_observers[$key]); } } public function notify() { foreach ($this->_observers as $observer) { $observer->update(); $observer->getMysqlValues(); $observer->matchValues(); $observer->getSearchValues(); $observer->sendEmail(); } } public function sendEmail() { //监听到subject在发email,告诉聘请了我的各位server $this->notify(); } } abstract class Send_Abstract implements IObserver { public function update() { //“简历信息”和"职位信息"在去查数据库之前，这里面的代码基本上是一致的，除了表名 } public function getMysqlValues() { //这里面的操作数据库得到数据的操作基本上也是一致的，除了表名 } public function getSearchValues() { //这里的操作是查询数据，操作好像也是一样的，还不知道，因为 //我只是把框架给设计出来了，功能代码还没写完呢... ＝ ＝！ } public function sendEmail() { //这里是根据找到的内容发email，操作好像也是差不多的 ＝ ＝！ } public function emailContentTemplate() { //因为发email时 “简历信息”和"职位信息" 使用的模板不同，在这里设置 //这里面留空，给子类写，但不定义为抽象的，因为不一定要使用模板 } } class SendPosition extends Send_Abstract { protected $_name = '这里设表名'; //这里和下面那些有调用父类的方法，都不是必需的 public function update() { parent::update(); } public function getMysqlValues() { parent::getMysqlValues(); } public function matchValues() { } public function getSearchValues() { parent::getSearchValues(); } public function sendEmail() { parent::sendEmail(); } public function emailContentTemplate() { //这里加载设置了"职位信息"要用到的模板 } } class SendResume extends Send_Abstract { protected $_name = '这里设表名'; public function update() { parent::update(); } public function getMysqlValues() { parent::getMysqlValues(); } public function matchValues() { } public function getSearchValues() { parent::getSearchValues(); } public function sendEmail() { parent::sendEmail(); } public function emailContentTemplate() { //这里加载设置了"简历信息"要用到的模板 } }

 

上面我没有让实现类直接继承IObserver接口，因为实现类的操作很多都重复了，所以我就多加了一个Send_Abstract做为最终实现类的父类，并把相同的代码写在了父类，这种思想好像也是一种设计模式 ＝ ＝！ 忘记叫什么了.... 。

我没有使用php SPL中的 SplObserver，不过现在想起来使用SplObserver也不错，SplObserver中只要求实现一个update方法，上面的代码可以改为，如果Send_Abstract的两个子类继承IObserver接口的方法的执行顺序一样，就可以将上面的代码 $observer->update(); $observer->getMysqlValues(); $observer->matchValues(); $observer->getSearchValues(); $observer->sendEmail();

写到Send_Abstract的update方法中，否则写入继承Send_Abstract的两个子类的update方法中，这样还可以控制方法的执行顺序。

 

平生写的第一篇对于技术方面的文章。还真不知道上面的方面和思想有没有误导人 ＝ ＝！，留个纪念就好，以后还要坚持把学到的东西记录下来。。。。