Class versioning to support backwards compatibility

In the project I work on, we handle Medical Bil开发者_StackOverflow社区ling.

Every time the state makes a change to the official form (which our data classes represent), in order to maintain backward compatibility with previous forms, we add the new properties but leave the old ones intact, and have a document version property which is used to determine what validation is done and UI actions to display it.

This has lead to bloated classes over the life of the project (almost 5 years of State-mandated changes), and simply not supporting old document formats is not an option.

I would like to try creating a new class for each document version, but even then we will have several copies of very similar (though slightly changed) code. And class names such as ProgressNoteV16, ProgressNoteV17 look horrible.

Inheritance can't be used, because that would still result in the same problem (classes having properties that are no longer needed). Interfaces would make the Interface just as bloated, which wouldn't solve the issue.

What are the solutions and best practices used to solve this problem?

This is a fairly classic problem for any agency that works with the public in any capacity, especially if its a government or government monitored agency. The solution is non-trivial, and it will probably require some significant work to create, as well as maintain afterwards.

This has worked for me in the past when dealing with similar issues for clients, it might not work for you though, you will need to draft out what your trying to accomplish and if it makes sense to do this.

There are a couple of patterns to be familiar with (if you arent already):

1. Factory which has already been previously mentioned
2. Composition which will hopefully get you out of some of the ugly inheritance problems
3. Template for separating out the logic of what the form does from the versions

There are two books that are pretty good for explaining these (and a few other useful ones):

1. Head First Design Patterns (Cant remember off the top of my head)
2. Patterns of Enterprise Application Architecture (Fowler)

Now to the process I have used in the past:

1. Start by taking all of your current versions of the forms, separate them into different classes and look for common overlap. You can do this in draft mode or as your current plan to have different classes for each version
2. Derive from this class structure a number of "base" objects which you can use to be the inheritance root for each significant set of versions for a form. You may have several of these, but they should be less than you have total form objects.
3. Now in each of these base objects, group together common functionality (i.e. Name and Address structures, etc) and abstract this out into its own class hierarchy, inject this hieararchy back into your base classes through constructor injection.
4. Apply the composition pattern to your base class hierarchy now and work to get as much common class structure out as possible. Ideally your forms at this point would just be the minimal functionality that has changed in each form and have a constructor that takes all common (and perhaps slightly varying) functionality.
5. Apply the Template pattern now to abstract out all of the common "functionality" from your classes, such as common validation, and persistence logic, use constructor injection again to get this functionality back into your base classes.
6. Extract Interface adapter definitions from your base classes and use these as the basis for your application to work with your forms
7. Build your factory classes to handle all the grungy work of setting this up.

Hope that gives you some ideas of what to do.

If inheritance can't be used "because fields in the document can be removed", how do you handle that at present?

Depending on the details of your design, you should be able to override the fields unused by the current version of the document (i.e. override in a subclass for that document) and throw a NotSupportedException or similar in the implementation of that method if the form tries to assign a value. By a similar logic, you can (and probably should) use interfaces... just knowing that a concrete implementation may throw an exception for a property that it implements but that is not defined for that version of the UI.

You can use the Factory Pattern to return an appropriate instance of the object for the given form version.

If there is some commonality between code that's slightly changed but mostly the same, you may be able to refactor some of that commonality into a private/protected method that is used by multiple public methods.

As for class naming, if you use the Factory Pattern you can refer to the class in most of your code using the interface. Only the factory itself would need to deal with "odd" looking class names.

I would implement this in a far more loosely coupled way - a class containing two fields: a version and a dictionary. When data changes this much it gets very tedious to try and keep track of the properties that are lost and added. With a dictionary you can simply test to see if the key exists.

Without any further details of your code, I think you could probably try Decorator design pattern ideas... Take a look at this article: Avoid Excessive Subclassing with the Decorator Design Pattern

Checking Patterns for things that change with time by Martin Fowler is also a worthwhile reading to get useful ideas for this kind of design scenario.