Question

My application receives XML messages to update it’s data objects. The XML message contains details on how the data is to be modified. The XML looks something like:

<data>
   <stuff> .... </stuff>
   <stuff> .... </stuff>
   <objs>
      <obj attr1=... attr2=... />
      <obj attr1=... attr2=... />
   </objs>
</data>

How should I update the fields of the objects?

1. Create a modify(String xml) method. Parse the message, extract <stuff> data, then reconstruct the following <obj attr1=... /> as a String and pass into modify().

2. Create a modify(NamedNodeMap xml) method. Parse the message, extract <stuff> data, keep the results of the parsing (Document object), find the relevant Node and pass into modify().

3. Create a modify(String attr1, String attr2, …) method. Parse the XML, extract the fields, pass into modify(). Probably a very bad idea, because if I need more attributes, I need the change the method signature, and breaks everything that depend on the modify() method.

4. Create setters for every field. Parse the XML, then set the fields individually. Then we run into the whole getter and setter debate, and in the context of this application, the fields of my data objects should only be modified by these XML messages, not anywhere else.

Personally I’m torn between 1 and 2. I think 1 would be more flexible, in case we decided not to use DOM, I can change how the String is parsed inside the modify(String xml) method. But then I would have to parse the XML twice, once to obtain the <stuff> data, then reconstructing the XML as String, and being parsed again inside the modify() method.

Should XML parsing even be done inside my data classes? Is there any reason to choose the other choices? Thanks.

[Edit]
In general, how much should I “unpack” data before passing into a method?

Answer 1

I’d suggest option 4, mostly because you probably don’t want your data objects to be so closely tied to the message transport mechanism.

With options 1 and 2 if you decide to change your XML schema (or if you decide that XML is too verbose, or if you want to include encryption etc etc) then you probably now have to change your data object implementation – the same reason that option 3 is bad.

Are you absolutely certain that your current set of XML messages will be the only reason that data will change, ever? I mean really absolutely 100% certain that no-one will ever not want to use XML? If not, then go with 4. Decoupling implementation (data object) from interface (XML messages) is the best way to ensure your code is maintainable.