OOP over the top

From Jarno VirtanenI found a link to an article titled Understanding Object Oriented Programming. Wow, all I can say is go read it and then you'll know exactly how not to build a maintainable system. I'll refer you back to my post on the pain of over abstraction. In that post I was criticizing the design of many Java APIs, especially XML APIs, however this is really a general problem with OO development. Fancy object oriented architectures have become the goal and this article maybe makes that point more clearly then anything I could ever say. It's representative of the thinking from a few years ago (written in 2000), and shows us just how much damage we now have to undo. It basically says that the simple solution that just works is wrong and will be unmaintainable. Maybe that's true, maybe it's not, nowhere does the article consider the question of whether or not that code actually needs to be that generic. It simply says that the simple solution is bad and that the seven class monster they came up with is the right solution. Talk about doing a disservice to students trying to learn how to build solid computer systems.

OO techniques are a tool, they are not an end goal. Starting to design a system to achieve OO purity is the fastest way to build a system that will be ten times more complex then it likely needs to be. This article was actually written in 2000 and thankfully Agile development methods that understand this distinction have been gaining substantial mind-share since then. Hopefully Pace University and King's College London are no longer teaching their students that this is the "right" way.

BTW, Simon Willison has posted an alternative solution and says "smart data-driven programming beats over-engineered class-based programming any day of the week". All I can say is, I agree completely. Programmers like to write code, and personally I think write too much of it, way too much of it. Data-driven programming is a method that's been lost in all the OO hype, but it works, and I believe it's going to play an increasingly important role going forward. This will especially be driven by XML ubiquity. Syncato is my experiment in exploring XML based data driven programming.

In that spirit, here's my solution to the problem using XML, Python and Simon's mythical System.getProperty. Using XML here is of course overkill too, but it solves their original problem in a much more maintainable manner, requiring zero code changes to add a new system.

An XML description.

<os-list>
    <os>
        <name>Windows NT</name>
        <name>Windows 95</name>
        <name>Windows CE</name>
        <message>This is a Windows box and therefore bad.</message>
    </os>
    <os>
        <name>SunOS</name>
        <name>Linux</name>
        <message>This is a UNIX box and therefore good.</message>
    </os>
</os-list>

  

And a simple program to glue the pieces together.

#!/usr/bin/env python
import libxml2

list = libxml2.parseFile("os.xml")

name = System.getProperty("os.name")
message = list.xpathEval("//os[name = '" + name + "']/message")
if (len(message) > 0):
    print message[0].content
else:
    print 'This is not a box.'

  

This particular example was contrived in the original paper and it's contrived here too, however when you teach OO developers to think code first, you end up with lots and lots of code. Want to know the secret to building maintainable systems? Quit writing so much source code. Ask your self if that fancy OO technique you're about to apply is really necessary or if a simpler data-driven solution can solve the same thing. I'll argue every time that if a simple XML file can eliminate a dozen classes, you need a damn good reason not to use it. That's not saying that there aren't times when it's inappropriate. Like everything else, this is just a tool too, but I believe it's an under-used and extremely powerful tool.

Once upon a time we understood this, we used to drive systems off the data model, now it seems everything has to be objects. This presents a problem since relational data models have presented a persistent mapping problem into object oriented domains. And many of the techniques developed to solve the problem are some of the worst offenders of the too much code phenomenon. EJB entity beans are a pretty good example of this. Forcing an OO layer between the program and its persistence introduces so much overhead that it's often just easier to write a dozen classes to solve the problem. XML now provides you the ability to start small and scale up as needed. The model is always the same no matter where the data comes from.

XML is about options. For instance in this silly example I could have certainly used a simple tab delimited file or some type of properties file. However, there are benefits to this being XML. Obviously, XPath is a big one, but so is the ability to change the underlying data storage technique. To your application it's just XML, but underneath it could be coming from the file system, over the network via HTTP, from a native XML database or it could be an assembled document from an RDBMS, an LDAP server or just about anywhere. To your application, outside of changing the location of where to read the data, it makes no difference. This provides the ability to evolve the system over time well beyond what something like a properties file would enable. To boot, using XPath, it probably even takes less code to process. Could you do all this with a properties file? Sure, but you'd have to build it all your self because everybody else is using XML.

The key here? Don't insist on putting a fancy OO layer on top of the XML. In some cases that will help, but in most cases it's just overhead. XML has powerful tools, learn how to leverage them. XPath in particular provides a tremendous amount of power for very little effort. It's not suitable in every situation, but is a very good way to bootstrap a simple solution.

Posted by Kimbro Staken