Putting your old code to use in a new project

Hey everyone,

For the past few days I've been working on a chemical structure drawing tool, and even though I don't have that much time to work on it this week I've still been making progress. Now, I'm a really lazy programmer, so naturally any code from other projects that I can incorporate shall be incorporated. So it was a really tempting idea to borrow the structure rendering code I wrote for my chemical database program. (Aside: I wrote it last summer and I think the code is terrible ... how things change)

It was a nice setup at the time, there is a Renderer class which handles the actual drawing (via GDI), and a CompoundViewer class which updates the renderer, handles support for more than one compound, allows selection, deletion, etc., and more useful things. 

However, there are several problems that were keeping me from just dropping it in:

• CompoundViewer uses different representations of structures than I'm using now (the old approach was comparatively sloppier) 
• Chemical bonds store the index of the atoms they are bonded to instead of pointers (as they do now) 
• A lot of methods in the old implementation of Compound are absent from the new implementation

 Still, it seems a shame to have to rewrite something that works well. Plus, the code has had numerous fixes for odd issues that I would probably overlook when rewriting. So instead of rewriting the rendering code, I kept it and scrapped the rest. The reasoning? CompoundViewer contains a lot of functionality that is heavily coupled to the old implementation of Compound, and refactoring it would probably be more trouble than it was worth.

To salvage the Renderer class, I added three new interfaces (ICompound, IBond, and IAtom), and the new versions of these classes implemented them. The required methods/properties that went into the interfaces came directly from what the Renderer class used. The good news is that this turned out to be very painless, and each interface only contains a few methods/properties. I was able to get a test up and running that rendered a simple compound correctly.

When I begin on the GUI side of this project, I won't have to rewrite the important code that actually draws the compounds. As a bonus, the Renderer class maintains compatibility with the old versions since they implement the interfaces already. It's like you win twice!

Design issues: Keeping it simple and practical

On the project I'm collaborating on with a former classmate, we are really trying to make some good design decisions. Stuff like:

• Code reuse
• Decoupled design (ie. data separate from domain) 
• Testability (programming to interfaces) 

At the same time, we want to keep the design simple and easy to follow. One of the things we were trying to solve was handling very dynamic queries in an elegant way. And we came up with a solution. And it was elegant. It had everything based on some common interfaces, used generics to handle them, and even reflection sprinkled in.

And then we got rid of it in favor of a simple, more practical solution. 

Actually, he proposed the simpler solution. His solution was based on his practical experience developing applications. Although our elegant method would have been pretty cool, it would be less maintainable and take longer. And remember that in the end, your users don't care about your elegant solutions. They just want your stuff to work.