前些时候学习编译原理，同时也为 DocWizard 做词法分析技术的准备，于是便想出了一种词法分析内核。这个分析内核可以在不改变代码的情况下分析不同的 DFA。 分析器的基本构造 如图一所示，脚本 Scripts 进入分析内核 ParsingKernel，分析内核根据 DFA 规则作词法分析，生成单词序列 WordsSequence。 图一 其中的 DFA Rules

作用: 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。 UML结构图: 抽象基类: 1)Product:创建出来的对象的抽象基类. 2)Factory创建对象的工厂方法的抽象基类. 接口函数: 1)Creator::FactoryMethod:纯虚函数,由派生类实现,创建出对应的Product. 解析: 在这个模式中,有

定义：对象间的一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。 功能：搜索数据库，当有需要公布的数据将其用各种方式发送出去。 观察者模式无疑能很好的做到上面的要求，无论要多少种方式，只要增加多个继承之ITransfer接口的派生类即可,有很好的维护性。 以下是实际的应用.

在 Win32 操作系统提供的所有功能中，使用最广泛但最缺乏文档描述的也许就是结构化异常处理了（SEH），当你考虑 Win32 结构化异常处理时，你也许会想到诸如 _try，_finally 以及 _except 这些术语。你能在任何有关 Win32 的书中发现对 SEH 很好的描述（即使是 remedial）。即便是 Win32 SDK 也具备有相当完整的使用 _try，_

作用: 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 UML结构图: 抽象基类: 1)ProductA,ProductB:分别代表不同类型的产品,而它们的派生类则是这种产品的一个实现. 2)AbstractFactory:生产这一系列产品的一个抽象工厂,它的派生类是不同的实现. 接口函数: 1)AbstractFactory::CreateProductA和Abstr

作用: 动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator 模式相比生成子类更为灵活。 UML结构图: 抽象基类: 1)Component:定义一个对象接口,可以为这个接口动态的添加职责. 2)Decorator:维持一个指向Component的指针,并且有一个和Component一致的接口函数. 接口函数: 1)Component::Operation:这个接口函数由

展开 在挖掘展开（Unwinding）的实现代码之前让我们先来搞清楚它的意思。我在前面已经讲过所有可能的异常处理程序是如何被组织在一个由线程信息块的第一个DWORD（FS:[0]）所指向的链表中的。由于针对某个特定异常的处理程序可能不在这个链表的开头，因此就需要从链表中依次移除实际处理异常的那个异常处理程序之前的所有异常

作用: 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 UML结构图: 抽象基类: 1)Prototype:虚拟基类,所有原型的基类,提供Clone接口函数 接口函数: 1)Prototype::Clone函数:纯虚函数,根据不同的派生类来实例化创建对象. 解析: Prototype模式其实就是常说的虚拟构造函数一个实现,C++的实现机制中并没有支持