art of disassembly----chapter01----lesson11---how is a disassembler working----02

        Mapping of "processing" tasks to objects  将处理过程映射成对象

在一个纯面象对象的设计中，这个映射并不恰当，因为我把处理过程处理成对象。然而，我坚持解析任务由"parser"完成，解码任务由"decoder"完成，：

如下图：
                              

绿色的矩形就是代表着对象，Parser以机器字节流作为输入，然后输出解析后的一条条机器指令字节。Decorder以一条条机器指令字节作为输入，然后输出汇编指令。

以上就是我们反汇编器引擎部分的整体设计了。

其它的一些辅助对象

到目前为止你可能已经注意到了，我们的对象并未与用户进行交互。Parser可以直接向用户索要机器码字节流，但我不认识有多少个用户会直接这么用手动的输入机器字节流给Parser。同时，当Decorder解析机器码为一条条的汇编指令，它如果向用户展现它的成果呢？且一个个消息框怎么样？我们可能很自然的联想到用一个显示的控制台窗口来输出，但是这并不是必须的。到目前为此，我还没有提到过这个方面的事。那么谁将来做这个方面的工作呢？

下面的几个对象来完成数据的索取及数据的展示任务。

                                                     

Data stream provider 对象用来”产生“输入数据流，（机器字节流）,它用来产生这样的产品，而我们的Parser恰好是这个产品的消费者（Parser要使用这些字节流）。数据流可以来自PE文件，LE文件，一个运行中的内存地址空间等等。

在本项目中，我决定使用一个PE dump来作为Data stream provider

Rendering provider 是一个UI对象，它可以是一个控制台的输出，在一个对话框中以列表框来输出等等，要怎么来显示汇编指令在于Rendering provider的设计者。在本项目中，我有一个解码对象叫SimpleDecoder，它仅仅使用C++的std::count来显示。

Where is user?

现在，我们把这几个部分整合起来。毫无疑问，”user“是最重要的部分。在前面我已经描述过了，UI层将与用户进行交互。

                 

用户提供一个将要反汇编的可执行文件，我们的反汇编系统返回一个反汇编了的文件。

到此，我们的架构是完成了。