观察者模式-在wsnos中的应用以及拓展

为什么要使用设计模式

虽然设计模式并不是万能钥匙（如果世上真有此物的话），但设计模式可确保通过熟知和公认的解决方案解决常见问题。模式存在的实施基础在于：大多数问题其他人或开发团队已经遇到并解决了。因此，模式提供了一种在开发人员和组织之间共享可使用的解决方案的机制。无论这些模式的出处是什么，这些模式都利用了大家所积累的知识和经验。 这可确保更快地开发正确的代码，并降低在设计或实现中出现错误的可能性。 此外，设计模式在工程小组成员之间提供了通用的语义。

观察者模式（又称发布-订阅模式）

在系统设计中，当我们需要设计一个消息提示功能，让系统把提示消息发送到某一线程。同时为了使系统能够易于复用，需要遵守低耦合高内聚的设计原则（减少对象之间的耦合有利于系统的复用）。在这里，观察者模式是最符合条件的一种。

观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

观察者模式包含2个要点：观察者和主题。最贴切的例子：杂志订阅，杂志是主题，订阅者是观察者。当出版新杂志的时候，这个事件会自动通知所有的订阅者。这里的通知需要外部的支持（可以是中断、事件等）。根据OO基本的原则，针对接口编程，主题和订阅者一般都是作为接口。

这是2者之间的关系。2者都是抽象的类。观察者注册主题，表明它对观察的意向。当主题的某个状态发生改变，主题向通知者通知这种变化。当观察者不在希望观察主题时，观察者从主题中注销注册。这些步骤分别称为：注册、通知和反注册。

我们来分别介绍下这几个步骤，首先是观察者注册：

上图描述了注册序列，观察者调用Register方法，把自身作为传参。主题收到此引用后用Add方法将其保存到容器中，以便在将来某个时间状态发生变化时通知观察者。大多数观察者实现并非将观察者引用直接存储在实例变量中，而是将此任务委派给一个单独的对象（通常为一个容器）。

然后是观察者通知：

当主题的状态发生变化，主题调用了GetObservers方法来检索容器中的所有观察者，调用Notify方法通知观察者发生的状态变化。这里已经完成了观察者与主题之间的处理。

最后如果不想让观察者继续观察，可以反注册:

把观察者从主题的容器中移除，这样这样当通知产生的时候，主题再次调用GetObservers方法就无法找到观察者，也就通知不到观察者。

这样我们对观察者模式有了一个基本的认识，在大话设计模式书中，对观察者模式结构有了如下的解释：

图片暂时未上传。。。

上面说到的都是基于面向对象情况下的观察者模式，那么在C这种面向过程的语言中，是否可以实现观察者模式呢？下面就介绍一种方法，在C中实现观察者模式：

待续。。。。。。