文档解析的OO设计原则

Question

它的任务是创建一个软件应用程序，它将解析一组150个文档，提取某些数据元素(而不是html元素)，例如表、注释、无效内容、无效字符等。不幸的是，这些文档的排列或格式化方式似乎很少一致。例如，数据表从一个文档看上去可能与另一个文档非常不同，而其他文档可能永远没有表。

我成功地分析了7份最重要的文件。原来的要求只要求处理这些问题。最后，我创建了一个抽象类，该类为所有文档所需的公共解析提供了默认实现。我创建了7个实现类，为不一致的场景提供自定义解析。我知道这不是一种理想的设计方法，但效果很好。顾客非常高兴。

不幸的是，客户非常高兴，现在他们希望所有150个文件被解析！不用说，我不想创建150个实现类。然后，我拿出一个电子表格，对文档进行了7种不同类型的解析。所有文件都需要两种类型。然后，还有其他5种解析类型的组合，任何文档都可能需要完全解析。

现在我试着想出一个合理的设计方法。我的第一印象是通过可能的解析活动的接口，为所需的解析活动创建直接继承和组合的组合。例如，所有文档都有需要删除的标题和一组无效字符(空格太多、多次回车等)。有些文档可能有需要删除的数据表。其他国家将有需要删除的技术说明。

我已经想出了34个可能的解析活动组合。我是怎么得出这个的?2+ 5^2 = 34。我还没有完成对所有150个文档的分析，但看起来所有文档中的1/3到1/2可能属于三到四个解析活动的组合。

我需要想出一个好的设计来处理这七个解析活动，并且足够灵活地处理新的一次性文档，这些文档时不时地会让他们变得丑陋。

Answer 1

在文档结构的所有组合中，我很好奇您是如何将文档匹配到正确的解析器的。

在这种情况下，继承可能会成倍地增加类的数量。如果文档元素在一个文档和另一个文档之间有很大的不同，您可以对它们进行预处理/规范化以简化解析吗？我猜这些文档有某种结构，所以您可以解析它们并确定什么是什么，例如标题、通知、数据表？

我认为应该只有一个解析器来解析所有文档。解析器只是解析一个文档来提取元素。然后，它为特定类型的元素调用其处理程序，例如头处理程序、数据表处理程序等。处理程序当然是抽象的，您可以提供各种实现来处理特定类型的元素(可能是策略模式或责任链)。

如果您从一些默认的实现开始，这应该是很好的。如果处理程序无法解析某个元素，只需抛出一个异常，您就会知道它要么是代码中的bug，要么需要扩展实现。