有人建议使用一种设计模式来获取二进制数据文件，将其部分解析为对象并将结果数据存储到数据库中吗？

我认为可以使用类似的模式来获取XML或者制表符分隔的文件并将其解析为代表对象。

通用的数据结构包括：

(Header) (DataElement1) (DataElement1SubData1) (DataElement1SubData2)(DataElement2) (DataElement2SubData1) (DataElement2SubData2) (EOF)

我认为一个好的设计将包括一种基于文件类型或者标头中包含的某些已定义元数据来更改解析定义的方法。因此，工厂模式将成为解析器部件总体设计的一部分。

解决方案

回答

策略模式可能是我们要查看的一种。该策略是文件解析算法。

然后，我们需要一个单独的数据库插入策略。

回答

• 只需使用任何想到的方法编写文件解析器
• 为此编写大量的单元测试，以确保涵盖所有边缘情况

完成此操作后，我们实际上将对问题/解决方案有一个合理的了解。

现在，脑海中浮现的只是种理论，而其中的大多数事实都被误导了。

第三步：无情地重构。目标应该是删除大约一半的代码

我们会发现最后的代码将类似于现有的设计模式，或者将创建一个新的代码。然后，我们将有资格回答这个问题：-)

回答

我完全同意Orion Edwards的观点，这通常是解决问题的方式。但是最近我开始发现一些疯狂的模式。

对于更复杂的任务，我通常使用解释器(或者策略)之类的东西，该解释器使用某种生成器(或者工厂)来创建数据的每个部分。

对于流数据，整个解析器看起来像适配器，从流对象适应对象流(通常只是队列)。

对于示例，可能会有一个用于完整数据结构(从头到EOF)的构建器，该构建器在内部将构建器用于内部数据元素(由解释器提供)。一旦遇到EOF，将发射一个物体。

但是，在某些工厂功能的switch语句中创建的对象可能是许多次要任务的最简单方法。另外，我喜欢保持我的数据对象不可变，因为我们永远不知道什么时候有人将并行性推到了喉咙:)

回答

使用Lex和YACC。除非我们将接下来的十年专门用于此主题，否则它们每次都会生成更好，更快的代码。