Objects are Hammers (and traditional data structures are swiss-army knives)
15 March 2007 by manniwoodRemember 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 hell of a lot of sense for the OOP paradigm) sucks like an Electrolux in the business programming domain.
But the problem is, like so many ill-gotten fads foisted upon us programmers, OOP is all the rage now, and all these programmers are running around with these OOP hammers thinking every 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).
Now I don’t know why the hell I thought about crushing cars, but it just seems to me that a business’s data are a lot like cars or anything else: the important thing is what you’re going to do to the data, not the data themselves. (And when you are thinking of the data themselves, the relational model is what you are looking for, *not* OOP. That’s another post.)
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.
C, verb
C++, noun
C, action
C++, thing
C, do
C++, be
(Sinatra: doobeedoobeedoo.)
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 you’re probably thinking, well what about the STUFF? I mean, the stuff is objects, right? Business STUFF takes well to object-oriented programming, right?
No, not really. From a programming perspective, all businesses have one thing in common: they change their minds. All the fucking time. Twice on Tuesdays. So who the hell would take something as rigid as an Object hierarchy and use that for modeling a business process that will change in 6 months anyway?
Example: “Hey, Mr. programmer, we decided that registrants really do need a separate middle name field 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 in the ass, and way too rigid for most businesses, even though software is built like this EVERY DAY.
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; the relational data model is the most worthy model out there; again, a topic for another post); add a field on your form. Done. Really. I was using this really cool thing called a hash to shuttle the registrant record from the database all the way up to the form and back again. Cool thing about hashes: unlike Objects or beans (the stupidest pseudo-data-structure ever invented), hashes, one of the classic data structures, are purpose-built to have any number of fields without changing any code or re-compiling. Hashes are business-friendly.
See, in all the excitement about beans and objects, and all the dreck we’re supposed to be all hot and bothered about, knowledge of classic data structures has all but been forgotten, and that’s a real shame. Perl is probably the most potent expression of how you can do just about everything with lists and hashes, but every language still has these two classic data structures.
It pisses me off that these two extremely powerful data structures have been supplanted by objects and beans.
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.
There is so much wrong with this way of doing things, it makes me want to give up computer programming and take a minimum wage job where I *expect* things to be stupid and arbitrary.
First off, Object-Relational mapping is the Vietnam of computer science. It’s just wrong on so many levels. And bloody stupid, because it is based on a fallacy that you’d *want* to transform your data from a relational model to an object-oriented model, as though the object-oriented model were better. It’s not.
And all that hard-coding of fields in objects and beans. It’s just wrong. I’m not an agile programmer, but if I was, I certainly wouldn’t use objects. What’s agile about hard-coding all your fields? And here’s another thing: most business data really are business *data* and not business *objects*. If you’ve got a bunch of string data, organised as records and fields (and most business data are) why would you want to write all those getters and setters when you could just throw everything in a hash and be done with it?
OK, so here’s how I shuttle data from my persistence layer (a lovely relational database) all they way up to my display layer.
1) I use iBATIS. iBATIS is *not* an O/R mapper, it’s a SQL mapper. It actually assumes you’d *want* to write your own SQL instead of have some O/R mapping tool bungle the job for you. And you know what? If you’re a *real* programmer, you *do* want to write your own SQL, because it’s easier to write and think about business stuff in SQL than it is in just about any other way.
(Mini-rant. “Hi, I want to be a professional programmer. But, I don’t want to learn SQL.” Translation: “Hi, I want to be a professional baseball player. But I never want to learn how to throw balls. I just want to catch them.” If you don’t want to learn programming languages, don’t be a programmer. There, I’ve said it.)
2) When I fetch my data from iBATIS (notice I’m not using the word objects here: I just want my business data, not objects), I fetch it into a list of hashes. It’s all you need!
3) I hand that list of hashes off to my web front-end (displaytag is quite spiffy in this regard).
And that’s it! Form processing essentially is that in reverse: a form populates a hash with its values (*not* a form bean) and a function (or, alas, method) acts on that hash to throw it into an SQL insert statement. Done!
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 changing needs. Still not exactly fun, but *way* more manageable than changing a thicket of Java code, no matter how clearly-written. (And don’t even get me *started* on the fiasco that is XML.)
The relational model really is quite a beautiful way to model and store your business’s data. I’m enamored enough with it that I keep trying to make the layer between database and display (model and view) as thin as I possibly can. And I must say, slinging around lists of hashes is certainly the least painful method I’ve found so far.
One sure sign that our generation of programmers is *way* too enamored with objects is that most programming books I know of 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 so, so wrong.
You want to design the relational database *first* and then write code that makes it as easy and transparent as possible to get data in and out of that carefully designed database.
I developed a lot of this bias reading Philip Greenspun’s books, here and here. Almost all of the code samples in Greenspuns books are SQL, as if getting the data model right is the important thing and that, once you get that right, the rest of the site’s coding will pretty much seem straightforward by comparison. And you know what? He’s right!
Another thing Greenspun did was steer clear of Java. He did photo.net in Tcl. Personally, I’m not a huge fan of Tcl, but I certainly took away a valuable lesson: higher-level languages are *way* better business/web programming languages than lower-level languages like Java. Not only does Java really encourage you to use objects and beans, but it’s also statically typed, which is just *evil* for business programming. (More on that topic in another post.)
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.
