Question

Say we want to Parse a XML messages to Business Objects. We split the process in two parts, namely:

-Parsing the XML messages to XML Grammar Objects.
-Transform XML Objects to Business Objects.

The first part is done automatically, generation a grammar object for each node.

The second part is done following the XML architecture so far. Example:

If we have the XML Message(Simplified):

<Main>
  <ChildA>XYZ</ChildA>
  <ChildB att1="0">
     <InnerChild>YUK</InnerChild>
  </ChildB>
</Main>

We could find the following classes:

DecodeMain(Calls DecodeChildA and B)
  DecodeChildA
  DecodeChildB(Calls DecodeInnerChild)
     DecodeInnerChild

The main problem arrives when we need to handle versions of the same messages. Say we have a new version where only DecodeInnerChild changes(e.g.: We need to add an “a” at the end of the value)

It is really important that the solutions agile for further versions and as clean as possible. I considered the following options:

---

1)Simple Inheritance:Create two classes of DecodeInnerChild. One for each version.

Shortcomming: I will need to create different classes for every parent class to call the right one.

---

2)Version Parameter: Add to each method an Object with the version as a parameter. This way we will know what to do within each method according to each version.

Shortcoming: Not clean at all. The code of different versions is mixed.

---

3)Inheritance + Version Parameter: Create 2 classes with a base class for the common code for the nodes that directly changes (Like InnerChild) and add the version as a parameter in each method. When a node call the another class to decode the child object, it will use one or another class depending on the Version parameter.

---

4)Some kind of executor pattern(I do not know how to do it): Define at the start some kind of specifications object, where all the methods that are going to be used are indicated and I pass this object to a class that is in charge of execute them.

---

How would you do it? Other ideas are welcomed.

Thanks in advance. 🙂

Answer 1

How would you do it? Other ideas are welcomed.

Rather than parse XML myself I would as first step let something like CodesynthesisXSD to generate all needed classes for me and work on those. Later when performance or something becomes issue I would possibly start to look aound for more efficient parsers and if that is not fruitful only then i would start to design and write my own parser for specific case.

Edit:

Sorry, I should have been more specific :P, the first part is done
automatically, the whole code is generated from the XML schema.

OK, lets discuss then how to handle the usual situation that with evolution of software you will eventually have evolved input too. I put all silver bullets and magic wands on table here. If and what you implement of them is totally up to you.

1. Version attribute I have anyway with most things that I create. It is sane to have before backward-compatibility issue that can not be solved elegantly. Most importantly it achieves that when old software fails to parse newer input then it will produce complaint that makes immediately sense to everybody.
2. I usually also add some interface for converter. So old software can be equipped with converter from newer version of input when it fails to parse that. Also new software can use same converter to parse older input. Plus it is place where to plug converter from totally “alien” input. Win-win-win situation. 😉
3. On special case of minor change I would consider if it is cheap to make new DecodeInnerChild to be internally more flexible so accepts the value with or without that “a” in end as valid. In converter I have still to get rid of that “a” when converting for older versions.
4. Often what actually happens is that InnerChild does split and both versions will be used side-by-side. If there is sufficient behavioral difference between two InnerChilds then there is no point to avoid polymorphic InnerChilds. When polymorphism is added then indeed like you say in your 1) all containing classes that now have such polymorphic members have to be altered. Converter should usually on such cases either produce crippled InnerChild or forward to older version that the input is outside of their capabilities.