Best way to implement class library containing standards which changes yearly

Question

I want to create a class library for some standards. These standards are updated yearly (Not necessarily every year, may take 3-4 years also). I want to maintain older versions also. What is the best way to do it?

Currently I am thinking of following structure:

StandardName (namespace) --> Year(namespace) --> actual implementation of particular standards Class

problem here is, change in standard from one year to another will require copying all the class to new namespace also, although some of them may not be changed at all. Is there any efficient way ? Or am i missing someting?

Answer 1

Depending on your standard, OO handles this well or not so well. The most basic support is an interface which your classes need to implement. This means no reuse unless you start using delegates in your implementations.

Or, if the standard only ever grows (i.e. old functionality never changes), then you can perfectly support this by inheriting.

In the real world, you will do a mix of all three approaches. Common code will go into base classes and delegates, so you can just copy a few lines of code to get most of the functionality. The rest is then implemented from scratch or by overriding an existing implementation.

Answer 2

I think a proper encapsulation here is the key.

Some parts of the standard are bound to keep unchanged between versions so that some part of your implementation should be more or less stable.

If you know in advances which part is most likely to keep unchanged then you can pay special attention to the encapsulation of that parts so that you max out reusability. On the other hands, for the parts that are more likely to be refined you should abstract as much as posible... specially if the spec is bound to be expanded (adding some functionallity but keeping the old intact).

Don't be afraid to refactor between versions... you are probably going to get it wrong the first time. Instead of starting over or copy pasting the old sections to the new implementation, refactor your design, improve it, change it. As versions goes by, you'll be able to get a better understanding of how your specs evolve.

Answer 3

I assume that the same "standard" is pretty stable from year to year. If so, you should be able to keep the interface to this standard stable. So I would suggest you use a factory method which can take some argument specifying what particular year/version of the standard the client want. That allows you to hide the actual implementation, so clients does not have to bother with different namespaces at all. Also, you avoid unnecessary name clashes that way.

If the standard changes to much from year to year to keep a stable interface, you should still be able to reuse existing code by applying sound OO techniques such as inheritance and composition.

Answer 4

Your new classes probably need new names because they do something different.

Qt4 allows the user to enable a QtSupport option to gain access to Qt3 code when porting applications. By default, drop support of old code and make the user explicitly enable it. This way, the user can easily work with legacy applications with the newer version, but new projects won't use old code.

Answer 5

Requirement questions:

• Is the standard backwards compatible?
• Do several versions of the standard have to be able to coexist within the same application?

If your standard is backward compatible, you can inherit the classes from old versions when implementing new ones.

If it is not, but versions don't have to coexist, simply change the old source code as you see fit and make a new release every year.

If it is not backwards compatible, and several versions have to coexist, going with namespace separation may be required. Of course this might pose problems if your standard uses singletons, each version would then have its own, which might defeat expectations.

Bottom line: If at all possible, I'd avoid namespace separation, but you might need it.

Answer 6

I don't understand what your standards really are but sometimes you need to change only some coefficients, rates etc. (For instance, loans' interest or any current thresholds.)

If it is the case then I would prefer to store each value in the database along with the DateTime Applied column so I will have to perform the following query in order to determine current value:

SELECT TOP 1 Value WHERE Key = %A AND Applied <= GETDATE() ORDER BY Applied DESC

The pros of this solution is that if you know of some changes to be applied in some period of time (e.g. couple of months) then you can just add an appropriate database records and changes will be applied when the time is right. Cons are that it is difficult to store anything else but values and you need to design an appropriate caching so it won't hit your database for each access but will update it when new value applied.