选择正确的设计模式

Question

我通过进行API调用获得了一个合并的产品xml.Xml包含各种产品的数据，如P1，P2，P3等。 我需要编写一个Windows服务，我将在其中进行此API调用，解析xml，然后将其分解为三个单独的xmls..i.e.one，用于每个产品P1，P2，P3 ......等。 解析每个产品的xml的业务规则可能不同。

将来，我可能需要将相同的输入xml分解为新的附加产品P4，P5等。

我可以考虑使用策略设计模式来解决这个问题，以便代码可维护，将来更容易测试和扩展。 请问这是正确的模式吗？

感谢。

Answer 1

不要过早地应用任何设计模式。

编写最直接的代码，该代码有效且易于阅读。

当出现未来需求时，您可以返回并重新访问代码。只要它以清晰直接的方式编写，就很容易看出可以应用于清理代码并使其更易于阅读的常用模式。

Answer 2

@hasen肯定，从简单的直接设计开始是有意义的，但从（可能的）良好的设计开始将节省工作。

我认为责任链（COR）可能是这种要求的良好模式。我想数据来自（可能是顺序的）xml解析器。我们将数据（标签）流传递给标签处理程序链，其中链中的每个处理程序都能够处理一种类型的对象（或其中的一部分）。每个标签要么处理它，要么进一步传递给其他人。

这个链在运行时形成，它可以根据新标签和带有额外处理程序的产品进行重新组织，并提供扩展点。

这可能需要一些额外的功能来保持少数（元）标签处理程序处理内存（可能通过委派）。

虽然我没有想到完整的设计，但COR看起来更适合它。