Devil's Advocate: Theory into practice

Martin Brampton recently had call to try his hand at developing an open source software project – and in the process testing out some of theories he advocates. How did they stand up?

After my website was hacked a couple of months ago, I needed a fix for its file repository software. The site was almost wholly open source, but the developer of this particular component had disappeared to do other things. It didn't take me long to decide that it was payback time and I would have to write the changes myself.

As anyone who has worked with software knows, taking over somebody else's code is always tricky. While one might suppose that the logic of the application would dictate the code, there are so many different ways to achieve an objective that personal style becomes a major factor. And styles vary considerably.

So when the urgent fixes were done and the software re-established as a viable open source project, my thoughts turned to extensive rewriting. One factor was my commitment on principle to an object-oriented approach. Ever since becoming seriously involved with objects, I have been convinced that most software should be written in this manner.

Happily, this is a particularly viable thing to do for a web application. Object orientation works most easily with interpreted programming languages, and one of the most popular choices for web development is PHP. Version 4 contains a useful range of object constructs, and version 5 goes much further down that road, although it is yet to become widely established with large hosting organisations.

The rewrite project confirmed once again some of the great virtues of objects. Although the component worked as originally written, it was hard to understand and very tricky to modify without getting into trouble. Roughly similar pieces of logic turned up all over the code, but were difficult to turn into common routines.

Still, once a small number of objects were defined, the class methods gradually grew to meet the requirements of the overhauled logic. As is normally the case, most methods were very short, often only two or three lines. The general code that handled the logic behind the various display screens shrank rapidly as new methods were written. Naturally, the methods were grouped together by their link to the object, but it was also possible to group related methods.

The result was code that could much more readily be checked for accuracy, as the behaviour of the object was reviewed. While plenty of errors cropped up, many of them were easily corrected punctuation errors. Most of the logical errors proved easy to fix, with just a few times when interacting methods resulted in perplexity.

Although the total volume of code remained much the same, it will most likely run faster than before I got my hands on it. The logic is less dense because of the simplicity of most methods. Also, a factor increasing the volume of the object-oriented (OO) version is the use of long, relatively self-explanatory names. Those are quickly reduced to tokens by the processor, or can be pre-processed into a machine-efficient version that sacrifices readability.

But the most persuasive consideration was how gratifying it was adding quite complex features, once a good repertoire of object methods already existed. I have always argued that even if re-use across projects cannot be achieved for organisational reasons, OO is capable of producing re-use even within a single project. A carefully designed group of objects gradually builds a range of methods that become amazingly powerful.

Naturally, there is always scope for further improvement, and a refactoring of the whole design will be a worthwhile exercise at some point. For the time being though, I am releasing the work to the mercies of other consumers of open source web software, happy with the reassurance that principles I have regularly advocated can be put into practice. Not to mention the enjoyment of writing useful software.