Ben Nadel recently wrote a blog post on his disillusionment in his attempts to "get" OO. His conclusion was that he was going to have to give up on "object purity" and accept a more practical OO approach. Based on the comments on his post, a lot of people are feeling this.
Ben is a very smart guy and a great programmer, so what does it say that Ben is having such a tough time with OO? First, let me express my empathy with people who are trying to learn this stuff. Sean Corfield made the point that learning OO is hard. That's both very true -- and very unwelcome. And the point Ben is at is one that perhaps we all reach: I'm just going to do something that works.
Let me, though, offer an argument that the problem is not in either Ben or in OO, but in our perception of OO. I'm fond of asking the question, "What is an object?" I don't ask it to be deliberately philosophical or obscure, but because it's a very important question to find an answer to.
One very bad answer is that an object is the heart of a religion called "OOism" that promises its adherents technical salvation. Ben is finding out just how hollow an answer this is.
So what is an object? Let me offer a slightly unusual answer: an object is a data type. Just that. Similar to an array or a Boolean. The main difference between objects and other data types is that objects have more behavior associated with them than we're used to in more standard data types.
This answer is, I believe, important because it points to where we should -- and should not -- use objects. If your entity has significant behavior that should be associated with it, objects are a great solution.
In our world of technology, we're all familiar with the technology du jour. Remember how web services were going to "change everything"? Well, I don't know about you, but they haven't "changed everything". I use them when they're...useful.
The same is true for objects. Led (or, perhaps more accurately, misled) by false perceptions, some have tried to make objects the solution to all things. Need information about customers? Instantiate a bunch of customer objects, wrap them in a collection (an array will suffice, but a collection class preferably), then loop over them, calling the appropriate getters on the objects.
But if objects are data types, we must ask ourselves, "Is this the most appropriate data type?" We can force fit anything into an object, just as I once saw a developer who chose a decimal number for zip codes. The first five digits went to the left of the decimal point; nine-digit zips had their last four numbers as the decimal portion. He was not dissuaded from this scheme despite the fact that zips that begin in 0 are particularly ill-suited for numeric types.
So, what's the best data type for a information about customers? In many -- perhaps most -- cases, we have a data type that works very nicely: ColdFusion's query. It's concise and doesn't have the considerable expense of creation that objects have.
"But that's not real OO!" it will be argued by some. No, it's not. If that's what Ben (and others) mean by their decision to forgo "object purity", I applaud their decision to eschew objects. But, too often a poor compromise is made: the anemic data model. Here, entities are fashioned as objects, but they have little or no behavior (other than, perhaps, getters and setters). This really is the worst of both worlds: the expense and complexity of objects with none of the benefits objects can provide when they're the appropriate data type.
Some wit wrote that when you use regular expressions to solve a problem, you now have two problems. That same dictum might be applied to objects -- but multiplied. When we try to take data, stored nicely in relational databases and turn it into an object, we encounter the "data mismatch problem". Now, we need dependency injection mechanisms, data access objects, gateways, services -- ugh! That's a lot of work to display and possibly manipulate/massage plain old data. It's such a problem that people end up using frameworks like ColdSpring and Transfer or Reactor to try to cut down on the sheer drudgery. You had one problem; now, you have multiple problems.
I've related before that I'm privileged to work with my colleague, Maciej. Over the past couple of years, Maciej and I have tackled some pretty intense problems and found ourselves buried in complex code. And, repeatedly, one or the other of us will stop and say, "This is getting too complicated." And guided by this sense that we've made a misstep at some point, we'll rethink the problem. In every case I can think of, we found a cleaner, better, simpler solution. Our complex code certainly looked impressive, but its complexity was a result of our missing the essential simplicity of what we were dealing with. It may be simple, but it ain't easy.
In the case of objects, I hope Ben -- and others -- will persevere. Just as arrays aren't the solution to everything, objects aren't always appropriate, but where they are, they provide expressive power and simplicity that nothing else can match. The trick is getting to the heart of things. Then, there's no question of theory v. practice; it's a matter of what's appropriate for this situation.