Object Oriented Update Approach

Question

I've been tasked with maintaining an application originally written in VB6. It has since been imported into VB .Net and to say the least the code is anything but Object Oriented. The code is riddled with classes which contain nothing more than Public Shared attributes(variables) and methods(functions), the result of which restricts the application from opening more than one project at a time.

A project consists of a XML file which contains general project settings, as well as the location to an Access database which contains other project related data. Over the years the format of the XML file has been modified, and an update and versioning strategy has been adopted. The chosen strategy performs an update upon open whenever an old version is encountered. Thus far, updates have only consisted of rearranging data within the XML file or making database schema changes and moving data from the XML file to the database.

Having quite a bit of background in OOP it's easy for me to see that a project should be a self contained object which other objects interact with. However, I fail to see how to apply the chosen update strategy in OOP.

The problem of implementing the chosen update strategy in OOP has kept me from using OOP as of yet. If anyone has experience with such a task, or recommendations on how to proceeded I'd appreciate any assistance you can provide.

Answer 1

Build a class which reads the XML file in, and provides properties/methods/etc based upon the data in that file. When the class writes the XML file back out, have it format in the manner needed for the new version.

So, basically, the class will be able to read in the current version, plus all the older versions, but it will always write out the new version.

Data would be held in internal variables of the class, rather than having to scan the XML file every time you need something.

Adding a VERSION node to your XML file will also help in this case.

Answer 2

You might have answered your own question when you used the word strategy (i.e. the Strategy Design Pattern).

Possibly you could:

• Create a project class that knows nothing about conversions but accepts a strategy object.
• Create a hierarchy of classes to model each possible conversion strategy.
• Use a factory method to build your project object with the right strategy

Answer 3

I don't understand why this is a troubling problem. It could be solved in any number of ways.

If you want to do a full object oriented enterprisey type thing, you could take any subset of the following solution:

• Create an interface IProject which describes how other objects interact with a project.
• Create the current implementation of Project which implements IProject and can read and write to the current version.
• Extend Project for each past version, overriding the xml and database read methods and having the constructor call write when these classes are instanced
• For extra enterpriseyness, create a ProjectFactory, which detects the version of the file and instanciates the correct version.
• If further versions are needed, rewrite the current Project to do the same thing as past projects, accessing the new version of Project with all the reads and then calling write.

The advantage of this solution is that you can continue meandering about with different versions and each new version only requires the ability to be updated to from the previous version, with all previous versions cascading up to the second to last version.