log4cplus源码分析

1【引题】

虽然从本科起就学的C++，然后在工作的2年时间中也不断的在用C++写代码，虽然基本的语法和一些常用的库函数已经滚瓜烂熟，可是总觉得自己写的代码还不是很专业，特别是看到那些老外们写得代码，从设计，到编码风格，再到各种编程技法的使用有很多都是值得学习和领悟的。于是，就决定静下心来找点开源的代码来研习。

因为LOG4CPLUS代码量不是很大，而且功能也不是非常复杂，不就是记个日志么，呵呵（不过，后来我也很纳闷，记个LOG也能搞这么复杂，唉）。

2【整体设计】

LOG4CPLUS的整体结构还是比较清晰的（如上图），主要是由Logger模块、Appender模块、Filter模块和Layout模块来实现具体的日志功能。其它模块，如：AppenderAttachable模块和Hierarchy模块只是分别负责对Appender对象和Logger对象进行管理。

Logger模块主要是将用户输入的日志信息以标准的方式存储在一个叫InternalLoggingEvent的日志对象中。同时，Logger模块会存在一个Appender对象的列表appenderList，Logger会调用列表中每一个Appender对象来完成剩余的日志记录处理。这个时候，InternalLoggingEvent会做为参数传入Appender对象。LOG4CPLUS的作者在设计Logger模块时，采用PIMPL的设计方式，先通过Logger接口类定义接口，然后功能具体通过LoggerImpl来实现。接着，为了让Logger对象也具有管理Appender的功能，Logger和LoggerImpl分别继承了AppenderAttachable和AppenderAttachableImpl类。

不过，Logger、LoggerImpl、AppenderAttachable和AppenderAttachableImpl这4者之间的关系有点凌乱，采用桥模式应该更好一点吧，如下图:

Appender模块负责根据当时的上下文信息将合适的日志内容记录到具体的外围设备中去。不过在将日志记录到外围设备之前，Appender模块必须先完成日志的过滤和日志内容的格式化，这两个功能都是通过多态的机制实现的，Appender类里面只是一个Filter指针和一个Layout指针，具体的功能全由派生类去实现了。另外，我们知道一个Appender类可能要进行不同方式的过滤，所以，为了满足这个要求，Filter对象中添加了一个next指针，指向下一个Filter节点，这样Appender就可以通过这个next指针来遍历多有的Filter对象了（这个地方可以考虑用vector的方式来代替Filter中的next指针，虽然本质上是一回事，但这样做更加清晰易懂，也有利于维护）。Appender模块中定义一个Appender接口，最后这个日志内容是显示到屏幕上、记录到文件里面，还是MYSQL数据库中，则是由不同的Appender派生类去实现的。

Appender在记录日志之前，会通过Filter接口调用具体过滤器来决定该日志信息是否记录。Layout模块则是帮助某个具体Appender类在记录日志信息之前将其格式化。

Hierarchy类相当于一个容器，它将系统中所有的Logger对象以一种树形结构进行存放。每个Logger对象可以继承它的父Logger的一些属性，如：Logger优先级、Appender列表等。Hierarchy有一个很特别的地方：就是它的子节点可以先于它的父节点创建，这个特性是通过创建虚拟父节点（provisionNodes）来实现的。至于其具体的算法，有兴趣的读者可以参考它的实现代码。

3【对象工厂】

LOG4CPLUS中除了Logger对象是通过简单的工厂方法实现的以外，其它如：Appender、Filter和Layout对象都是通过较为复杂工厂模板类实现的。为了方便描述，这儿以Appender工厂为例，进行分析。

我们知道Appender有很多种，如：ConsoleAppender、FileAppender、SocketAppender等等。这每个具体Appender对象都是通过某个特定的工厂生成的，所以每个具体的Appender都有一个对应的工厂。这每个Appender工厂都遵循相同的接口：BaseFactory和AppenderFactory。然后通过LocalFactoryBase和FactoryTempl两个模板类实现这两个接口。最后将这每一个具体的Appender工厂对象都存放到AppenderFactoryRegistry对象中。AppenderFactoryRegistry通过MAP容器保持所有的AppenderFactory对象与其生产的具体Appender类名称的映射关系。这样PropertyConfiguration对象在读入配置文件之后，通过具体的Appender名称就能够在AppenderFactoryRegistry中找到对应的Appender工厂，它的createObject方法就能获得用户需要的Appender对象了。而这一切，除了PropertyConfigurator外，其它使用Appender对象的模块根本不知道其具体的Appender类型，这正是工厂方法的价值所在：将具体对象的生成与使用解耦。

4【PIMPL方法】

PIMPL原则即：pointer to implementation。通过在接口类中定义一个指向实现类的指针来，完成接口声明与实现的分离。PIMPL利用了一个c++的特性，就是定义一个类指针，编译器不需知道这个类型的定义，只要给出这个类的声明就可以了。要这样做的好处就是当实现类发生修改时，包含接口类.h文件的客户代码不需要重新编译。当然，你也可以通过将接口类定义为抽象类，实现类继承该类的方式来达到同样的目的。这两个方法都差不多，只是当你需要针对一个接口类定义多个实现类时，应该选择抽象类的方法；而当只需定义一个实现类的时候采用PIMPL方式更加简洁。网上有很多讲解PIMPL的文章，想进一步了解PIMPL方法的读者可以去GOOGLE一下。

5【智能指针】

LOG4CPLUS中的智能指针功能类似于BOOST库中的shared_ptr模板类，但是设计的没有shared_ptr那么精致。它是通过ShareObject类和ShareObjectPtr模板来实现的，如下图：

任何想要使用智能指针的类必须要继承SharedObject类，而该类负责记录该对象被引用的次数，当该对象的引用次数为0时，就会delete该对象。ShareObjectPtr用于封装某个SharedObject对象所有的指针操作，这样在使用ShareObjectPtr对象时我们就可以像平时那样操作指针了。有一个地方需要注意一下，就是在给对象引用次数计数时，是通过__sync_add_and_fetch和__sync_sub_and_fetch这两个函数来操作count变量的，在多线程环境下这两个函数比平时我们先加锁后计算的方法性能上要高出很多。

6【结尾】

LOG4CPLUS的代码虽然不多，但是代码思路清晰，结构良好，除了一些宏定义的理解需要花点功夫以外，大部分代码还是很容易就能看懂的。一些比较通用模块如：配置文件解析、智能指针等等，它们的设计思路我们在平时的开发中也可以去借鉴一下。

另外，LOG4CPLUS中还有一些有趣的东西还需要进一步去挖掘，如它的多线程处理机制、AsyncAppender模块的异步日志记录功能，这个便是我接下来要探索的东西了。