文本分析的三种典型设计模式

事件驱动：Parse-Handler模型（如：xml之SAX模型） 该模型主要有Parser和Handler两个组件。其原型大体如下： class  xxxHandler { public :     //  any event sended from Parser    ... }; class  xxxParser { public :    xxxxParser(InputSource *  source);      HRESULT parse(xxxxHandler *  handler)    {        //  analyze source and send event to handler       ...    } }; 该模型不规定Handler类型的详细规格，由Parser的实现者根据具体情况而定。 这种模型的核心思想就是由Parser类来具体分析文本的格式，而让信息真正的处理者Handler类从具体的格式中脱离出来，不再需要关心文本物理组织细节。 Tokenizer模型（如：编译器的词法分析器） 这种模型仅涉及一个Tokenizer组件。该组件负责将文本分解为一个个token。其原型大体如下： class  xxxTokenizer { public :    xxxTokenizer(InputSource *  source);       //     //  成功返回S_OK，如果遇到eof返回S_FALSE。     //    HRESULT next(TOKEN *  token); }; 其中分析的结果以一个结构体TOKEN表示。这个结构体如何设计，同样视具体情况而定。通常它看起来是这样的： struct  TOKEN {  UINT type;  union  {   DATATYPE1 data1;  //  当type = type1时   DATATYPE2 data2;  //  当type = type2时   ...  }; }; 有了Tokenizer，我们就可以轻易的遍历整个文档： void  visit(InputSource *  source) {  TOKEN token;  xxxTokenizer tokenizer(source);   while  (tokenizer.next( & token)  ==  S_OK)  {   print(token);  } } token应当如何划分，其粒度如何，完全取决于设计者的考量。以以下一段xml文本为例：  <elem attr="value">content</elem> 你可以划分为：   < elem     //  element start  attr = " value "    //  attr-value pair  content     //  content   </ elem >      //  element end 也可以将attr-value pair细分为三个token：attr, assign-symbol, value。 你甚至也可以将整个element作为一个token。 从广义上来说，我们文件系统提供的字节流本身已经是一个Tokenizer了，只不过它划分的token是一个个并无多少逻辑含义的character。 而我们后面提到的DOM模型，也可以算是一个Tokenizer。只不过它划分的token只有一个，就是DOM树，与文件系统的字节流走的是另一个极端。 Tokenizer方式与Parse-Handler方式设计思路，最大的不同在于具体处理信息的人主被动地位相异。在Tokenizer模式下，信息处理者调用Tokenizer得到分析数据，如果相邻的token存在上下文关系，你可以根据需要去取得下一个token，故处于主动地位。 而Parse-Handler模式相关死板一些，一方面Handler类实现者才是真正试图处理信息的人，但是实际上对信息的划分（token）却是由Parse规定的，未必完全符合Handler类的需求。另一方面在token存在上下文关系，当前接受的数据信息不足时，Handler类无法随心所欲的取得下一个token（因为从流程上它是被动的数据接受方），而只能暂时缓存数据，等待下一条信息的到来。 文档对象：DOM模型 DOM模型是最高级的一种模型。它的思路是将文档完整地读入内存，并提供数据访问接口。 DOM模型消耗的内存最多，可提供的服务（我们可以联想一下xml的诸多应用，如xslt等）也最为完整。 这里提到DOM模型消耗的内存最多，这种说法并不全面。例如，在将它与Parse-Handler模型相比时，我们只是计算了Parser的开销，而Handler类是客户实现的，内存开销多少，无从计算。 另一方面，由于DOM模型可以按自己的方式组织数据，它在内存开销上的可优化余地很大，并且客户在使用它时通常不再需要大量的内存分配操作；而Parse-Handler模型中，Handler类的实现者出现蹩脚的设计可能性非常高，计入Handler类的内存开销的话，有时甚至可能远远超过采用DOM模型。 因此我个人认为相对于DOM的能力而言，内存问题在DOM模型中并不算一个了不起的缺陷。实现者可以有很多技巧来进行内存优化。 但是DOM模型有一个问题，就是它一开始就将文档完整的读入了内存，使得它无法胜任那些对响应时间要求较高、希望能够渐进处理的应用。而这一点是采用Parse-Handler模型和Tokenizer模型的好处。 后记 这篇文章写得比较早，因为最近写 WINX可视化开发工具 相关的设计稿时用到，所以整理了下。我个人在文本文件和各种文档格式的文件打交道较多，多年来也算是形成了一定的经验。我个人现在越来越倾向于采用DOM模型来处理文件。原因在于采用DOM模型有很多优点： DOM模型是提供了最高级的服务，模块的客户负担少。    模块划分极其清晰，方便维护。通常DOM模型的内部仍然建立于SAX模型（或Tokenizer模型）上，但是这种依赖局限在DOM模型的内部。因此，程序通常会划分为3层：    SAX（或Tokenizer） ==> DOM模型 ==> DOMClient（实际的应用）    内存管理方面的可优化余地大。在多数情况下，我们建立的DOM模型是只读的（或允许进行少量修改），这种情形下，内存管理方案可以以最简洁的方式实现。下文我们详细讨论这一点。在此之前，我推荐你回顾一下《 C++内存管理变革：最袖珍的垃圾回收器 》。    易获得更好的性能。虽然理论上来讲程序建立在SAX模型性能上可以获得更好的性能，但是经验表明，在团代开发的情形下，采用DOM模型的性能通常可优于建立在SAX模型之上的同样功能的复杂程序（不是简单打印或提取有限数据的情形）。