Manni Wood

Remember that old addage, “If all you have is a hammer, every problem looks like a nail”? Well, I’m here to tell you, objects are hammers.

Let me warn you that my biases are based on the problem domain I work in: database-backed, interactive websites for businesses.

And the sad thing is, object oriented programming, while perhaps good for other problem domains (I think GUI programming makes a lot of sense for the OOP paradigm) is terrible in the business programming domain.

But OOP is all the rage now, and many programmers are running around with these OOP hammers thinking every programming problem looks like a nail.

But businesses just don’t run that way. Let’s say you crush cars for a living. Do you make cars that crush themselves? I don’t know a single car that would do mycar.crush(). No, if you’re in the car-crushing business, you put a bunch of cars through a crusher: my_crushed_car = crush_car(my_car).

A business’s data are a lot like those cars: the important thing is what you’re going to do to the data, not the data themselves.

Have you ever heard the comparison of functional or procedural languages compared to OOP languages? Functional/procedural languages are verb languages, and OOP languages are noun languages.

functional/procedural: verb
object-oriented: noun

functional/procedural: action
object-oriented: thing

functional/procedural: do
object-oriented: be

Think of the phrase “model a business process”. Doesn’t a process sound more action-oriented and “verby” to you? It does to me. The idea of most businesses operating on their data is: take this stuff and do something to it so that it becomes other stuff.

Now it’s fair to ask: but what about the stuff being acted upon? I mean, the stuff is objects, right?

No, not really. From a programming perspective, all businesses have one thing in common: they change their minds. All the time. Requirements change. So who would take something as rigid as an Object hierarchy and use that for modeling a business process that will change in 3 months anyway?

Example: “Developer, we decided that registrants really do need a separate field for the middle name after all.” OK, so now I add a column the table in the database… and add a field to the object persistence layer… and add a field to the object display bean… and add an extra input to the form. There may be more layers in the object layer cake, but suffice it to say that this is a pain. Not using objects to represent your data can really alleviate this pain. (But I sadly acknowledge that multi-layered software with lots of OOP representation of business data is written every day. That doesn’t make it right.)

Here’s another way to do it: Add a column to the table in your database (can’t get around that one! — but that’s OK; use your RDBMS as the final representation of your business data); add a field on your form.

Done.

Really!

For every other layer in your software layer cake, use a simple map (or hash or dictionary) to shuttle the registrant record from the database all the way up to the form and back again. Cool thing about maps: unlike Objects or beans, they are purpose-built to have any number of fields without changing any code or re-compiling. Hashes are business-friendly.

A whole post could be written about how Java beans tried to make a generation of programmers ignorant of traditional data structures! But the argument I’m trying to make, is that oftentimes, lists and maps are all you need, and their flexibility is a real boon in the specs-are-always-changing world of business software programming.

Let’s say you’ve got a page on a web site that shows a tabular report resulting from a SQL query.

The commonly-accepted way to do this is to use an Object-Relational mapping tool to get your collection of objects out of the database and then do whatever transformations you need to do to show them in a tabular report. I’ve seen architectures that had data retrieval beans, and mapping code to display beans, which were then sent up to the (usually JSP) display layer.

There is a waste of time. As I’ve stressed above, if you can just use lists of maps, and sling those around every part of your application, your life becomes a lot easier.

And as a side note, Object-Relational mapping is the Vietnam of computer science. The way to avoid mapping objects to your relational database is to not use objects. Lists of maps very easily substitute for SQL result sets. Mapping problem solved!

(Another side note: shouldn’t agile programming be pushing for the use of traditional, flexible data structures instead of hard-coded beans? Maybe they are, and I haven’t been paying attention.)

I should note that even though I don’t use object-relational mapping, I do use a SQL mapper called iBATIS. It basically lets you write dynamic SQL: instead of hiding SQL from you, it requires you to write SQL, but gives you tools to make writing your SQL easier, and gives you tools to more easily transform your SQL result sets into lists of maps. Beautiful!

When my business clients change their minds about how their data are stored, I’ll happily change the database to accommodate their needs. Modern SQL implementations put so many ALTER commands at your disposal that it’s not too onerous a task to change your database with your client’s evolving needs. Everything in my business layer is lists of maps, so that doesn’t change unless I have to act upon the new field (at which point, it’s a legitimate reason to be changing your business layer code anyway). Same goes for the display layer: it will change if the new field has to be displayed, but again, that’s a legitimate change, not a work-for-work’s-sake change.

One sure sign that our generation of programmers is too enamored with objects is that a lot of programming books and blogs assume that you want to model all of your business’s data in objects, and then find a way to squeeze those objects into a relational database.

This is the wrong approach.

Use the RDBMS as the final arbiter and representation of your data model, and your problems go away. The relational data model models business data way better than OOP.

Alas, I’m stuck doing my current project in Java because it’s a standard. At least Java has Lists and HashMaps. It’s a bit of a struggle to make Java behave like Perl, but it’s worth it. ;-)

My pal Dan, on the other hand, gets to use Python for all of his web programming. He’s probably at least twice as productive as I am just because he doesn’t have to type

String iHateJava = (String) someHashOfBusinessData.get(“FIELD”);

Nope. He gets to type

iLovePython = someHashOfBusinessData["FIELD"]

and he’s a much happier person for it.

(Update: Dan tells me he actually gets to type

iLovePythonEvenMore = someHashOfBusinessData.FIELD

because he uses something called a dtuple.)

Now Dan is so enamored with the relational data model, he’s trying to move it up into Python. I have no idea how that will turn out, but I’d much rather see the RP (relational programming) paradigm take over the OOP paradigm any day.

Objects are hammers. And traditional data structures are swiss-army knives.