圍繞StAX解析設計類
[英]Designing classes around a StAX parsing
問題描述
這是一個設計問題，而不是特定於Java的問題，但是我正在為Java設計它。
我一直在編寫一些XML拉式解析類來處理自定義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實例的映射並使用反射來實例化適當的解析器（因為並非始終需要所有解析器）。 或者...改用反射來獲取適當的靜態解析方法 ，所以我不需要實例化實際上只是1用類的解析器...
是的，我想得太深了，但是由於這只是一個個人項目，我只是對人們如何圍繞StAX解析器設計解析類感到好奇。
3 個解決方案
解決方案1
4 已采納 2011-01-17 14:26:44
因此，取決於RequestId（排序鍵），Body元素是不同的。
您是否可以重新設計XML，以使有效的主體元素不依賴於請求ID，而是完全由周圍的響應元素決定？ 然后，文檔有效性（符合DTD）將與消息響應有效性相對應。
與其使用switch語句，不如考慮使用狀態設計模式 。 也就是說，將您的文檔處理程序實現為有限狀態機。
解決方案2
2 2011-01-17 15:45:46
我絕對會為每種請求類型選擇一個單獨的處理器類。 您的工廠方法聽起來不錯，但是不要為反射問題而煩惱，只需創建那些處理器對象而不是使用反射，三十多字節的堆空間對於易於閱讀的代碼來說是非常合理的價格。
不過，對於StAX而言，一件重要的事情是，在每種處理方法的文檔中，您都應該描述該方法期望輸入處於何種狀態（例如：處理了<body>標記之前或之后）以及它離開的位置處理后的輸入。 這樣您可以節省調試時間。
解決方案3
1 2011-01-17 16:29:20
除了將解析每個自定義XML對象的職責放在StAX解析器上之外，為什么StAX解析器不創建XML對象的中間表示形式？ 然后，您可以擁有一個工廠，該工廠將使用RequestID構造XML對象的最終表示形式。 該代碼類似於：
IntermediateObject io = StAX.parse(XML);
FinalObject = Factory.create(io.getRequestID, io);
使用這種方法的好處是您要分離職責。 StAX解析器將僅解析XML，而工廠將負責對該信息進行進一步處理。
使用Stax進行DTD解析
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.