views:

61

answers:

2

I'm currently working on a project which will support multiple file writing specifications (imagine if you had to support something like XML 1.0, XML 2.0, XML 3.0, etc) called ADIF. Currently there are two standards (version 1.0 and version 2.2.2), and they are both used commercially and both still heavily used.

Specification version 2.2.2 incorporates much of version 1.0 but there are some slight differences which rules out some inheritance and other OOP tools.

How would you organize your project to support older versions, yet continue to keep up with new standards.

  • Namespaces (Standard.Version1, Standard.Version222, Standard.Version223 (next version?), etc.) in a single class library? Seems sloppy.
  • Separate class library for each in the same solution (Version222.dll, Version223.dll, etc.)? Seems excessive.
  • etc.

I do intend to implement some code which will convert from one version to another.

Basically, I'm looking for some advice on how to best organize this type of project.

http://www.adif.org/

+1  A: 

You stated that there isn't a good inhertance hierarchy that you can implement?

If so I would recommend that you follow the namespace technique for your library, which can use any commonality possible inside the dll to reduce the work load for yourself. Having two api's will make it significantly easier for you to test and also nicely deal with issues regarding the differences between versions.

i.e. your version 2.2.2 api would only accept objects of the 2.2.2 version to prevent issues in the library. Good luck with whatever you implement :)

Spence
A: 

Specification version 2.2.2 incorporates much of version 1.0 but there are some slight differences which rules out some inheritance and other OOP tools.

Object composition can be a much more powerful tool for OOP than inheritance, which is IMO overused.

What ways can you find to break the problem down into simpler subsystems?

Rich Apodaca