Question

这是一个设计问题，而不是特定于Java的问题，但我正在为Java设计它。

我一直在编写一些XML pull解析类来处理自定义XML响应，当我设计它们时，我不禁想到是否有更好的东西。也许有人甚至有一个设计模式。

所以，这就是我的XML的样子：

<ResponseRoot>
  <Header>
    <RequestId />
    <OtherHeaderMetaData />
  </Header>
  <Body>
    ...
    <!-- Lots of other elements and nested elements -->
    ...
  </Body>
</ResponseRoot>

因此，根据RequestId（排序的关键字），Body元素是不同的。鉴于这是拉解析，我有一个大的switch语句和许多if-else-if块。

对于一个具有大量静态方法的类来处理整个XML流是否会更有效，或者它是否会为更好的设计提供一个类来负责每个RequestId？

我正在考虑将RequestId映射到类名，然后当我点击Body时，我使用工厂来检索相应的子分析符。在该工厂内部，我甚至可以使用Class实例的映射并使用反射来实例化适当的解析器（因为不是所有的解析器都是一直需要的）。或者......使用反射来获取适当的静态解析方法，所以我不需要实例化只是一次使用类的解析器......

是的，我的想法太深了，但由于这只是一个个人项目，我对人们如何围绕StAX解析器设计解析类感到好奇。

Answer 1

因此，根据RequestId（排序的关键字），Body元素是不同的。

您是否可以重新设计XML，以便有效的主体elemt不依赖于请求ID，但完全由周围的响应元素决定？然后文档有效性（与DTD的一致性）将对应于消息响应有效性。

请考虑使用state design pattern，而不是使用switch语句。也就是说，将文档处理程序实现为有限状态机。

Answer 2

我肯定会为每种请求类型选择一个单独的处理器类。你的工厂方法听起来不错，但不要理会反射的东西，只需创建那些处理器对象而不是使用反射，三十几个字节的堆空间对于易于阅读的代码来说是一个非常合理的价格。

有一点很重要，尽管使用StAX，在每个处理方法的文档中，您应该描述该方法期望输入处于什么状态（例如：在处理开始<body>标记之前或之后）它在处理后留在输入的哪里。你可以用这种方式节省数小时令人沮丧的调试。

Answer 3

为什么不让StAX解析器创建XML对象的中间表示，而不是将每个自定义XML对象的解析责任放在StAX解析器上？然后，您可以拥有一个工厂，它将使用RequestID构造XML对象的最终表示。代码看起来类似于：

IntermediateObject io = StAX.parse(XML);
FinalObject = Factory.create(io.getRequestID, io);

使用这种方法的好处是你要分担责任。 StAX解析器只会解析XML，而工厂将负责使用该信息进行进一步处理。

围绕StAX解析设计类

3 个答案: