利用Observer(观察者)模式实现系统日志

最近在做一个小项目，定时计算一些金融指标。在系统运行过程中，可能会由于数据等原因出现不同的错误。但由于系统会在服务器上7*24小时运行，出现一些无关大局的错误不该影响系统计算其他指标，但必须把错误记录下来。

其实这非常容易实现，只要在出现错误的地方调用写入日志的函数即可。

但问题是，当出现错误时，错误日志不一定被写到文件中，或许会被输出到界面上的一个ListView中，甚至通过网络发送。

比如

(error)
{
    WriteLogToTxtFile();
    WriteLogToListView();
    SendLogToNet();
}

当然，这三种方式都只是假设，并且如果再增加新的方式，我可能要在所有出错的地方都增加新的函数调用。

你可能会说，写一个函数叫WriteLog()，在里面封装各个写日志的函数

像这样

 

 1if(error)
 2}

 

这当然可以，但不够优雅。或许这马上让你想起了什么！对，观察者模式。

 

观察者模式--

      定义对象间一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

 

其实观察者模式大多数情况下是用来处理UI操作的。比如一个按钮被点击时，N个观察者做出反应。但在这个例子中，被观察对象不再是UI控件，而是系统输出的日志。

 

 1Code
 2//日志结构体
 3struct defLogNode
 4;

 

这样，在系统初始化时，只需要

 

1    CLogAdminPtr log = CLogAdmin::GetInstance();
2    log->AddErrorObserver(new CLogToFile());
3    log->AddErrorObserver(new CLogToDebugOutput());
4
5//当增加一种输出方式时，只需要派生一个新的子类，并在上面代码之后加入一行

 

如果没接触过观察者模式，其实这个问题也很好理解。我们在设计面向对象程序时，总是遵循一定原则的。

 

首先，依赖倒置，低层结构要依赖于高层结构。在这里，调用错误日志的地方就是高层结构，而具体的方法则是低层结构。如果想文章一开始那样，则是让高层结构依赖于低层结构了，程序便出现了偶合，因为在每个地方都要知道所有写入日志的方法。

其次，单一职责，当需要记录日志的地方必须知道有哪些写入日志的方法时，便使其职责不再单一。

第三，开放封闭，开放--对扩展开放；封闭--对修改封闭。这里的扩展，指的就是扩展具体写日志的方法。修改，就是当增加一种写日志方法时，不该修改系统已有的程序。