Design Patterns for Multi Version Support

[JamesMc86]

Hi All,

 

OK, so the titles a bit vague as I have yet to figure out the correct terminology for this. I'm working on an app with a couple of areas at a high risk of change/versioning.

 

In essence it comes from the fact that there is a central server and 100+ distributed nodes collecting data. As time goes on, features are added or changes are required on the nodes and we need the servers to be able to support the new version but also any older versions that are out there. Examples of what I mean are:

• Communications protocols could change as the networks change and support improved methods.
• File schemas almost certainly will change as firmware gets upgraded to capture different measurements or values.

What I haven't managed to find yet is recommended design patterns for handling these changes. The obvious one is to take advantage of dynamic dispatching although I have concerns about the two obvious methods I can see of doing this:

1. You can create an abstraction layer and have all version be a child of this, however we don't know which sections will change and could end up having to repeat code in each child, which leads to:
2. v1 is the parent, v2 is a child of v1, v3 is a child of v2 and so on. This seems like the natural way but I have seen some concerns over performance of deep heirarchies and I may end up still fudging sub-versions to avoid creating a new layer for smaller changes.

I'm simply curious, are there any known good patterns out there? How have you managed with similar problems in the past? (I'm certainly not going to be the first person!)

 

Cheers,

James

[PaulL]

James,

 

You have taken an important step in identifying "a couple of areas at a high risk of change/versioning."

 

Some of the the Object-Oriented design principles that are helpful are:

"Encapsulate what varies.

Code to an interface rather than an implementation.

Each class in your application should have only one reason to change."

See http://smile.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/ref=sr_1_1?s=books&ie=UTF8&qid=1405959788&sr=1-1&keywords=head+first+object+oriented+analysis+and+design.

 

These principles are behind many of the Gang of Four design patterns.  For a change in communication protocol consider the Adapter Pattern.  This is probably a good choice for a changing file schema as well.  If you want to avoid repeating code, you may put the relevant pieces in common code that your solutions call.  For certain types of repetition (an algorithm changes, but the version of the algorithm does not map 1 to 1 to clients, which may be what you are seeing) use the Strategy Pattern.

 

Paul