OO is just another tool

The OOP (object oriented programming) debate seems to be back in full swing lately. Without even trying (who has the time?) I've stumbled onto more than a handful of articles pro and con on the use of OOP/D during the last month.

Today I found a post by Bruce Eckel where he answered a reader question about the usefulness of OOP and also points to the rant by Richard Mansfield (OOP Is Much Better in Theory Than in Practice) from a couple weeks earlier (referring to him as the machine-code guy which seems quite appropriate under the circumstances). For a different treatment on OO is bad the B. Jacobs site (referenced by Richard Mansfield) is an interesting read. No wildly crazy ideas like using copy and paste for code reuse there, but he does see everything as being easily modeled in a relational database (see the entry on table oriented programming).

What I found interesting about the response was the way that he'd evolved from assembly to higher level languages and patterns (I think of OO design and programming as an über pattern since the concept of patterns was introduced to me with the GoF book) in part because it so closely tracks with my own growth and experience.

It's been far too long since I made the transition from a purely procedural development methodology (a metamorphosis that occurred in fits and starts between 1988 and 1994) to gauge the arguments regarding lost productivity during the transition. Still, I'd have to acknowledge that there is a cost, as there is in learning any new tool. The only argument I'd consider to be valid for OOD/P having a negative impact on productivity is that once accustomed to object based designs, a desire to get the object hierarchy right the first time does set in; paralysis by analysis isn't entirely uncommon. I wound up using an XP'ish approach, putting the code that didn't fit into the object view elsewhere until enough of it accumulated to make a sweep and clean up in a sane manner.

One thing I haven't seen yet from the OO luddites is an attack on object oriented design concepts (perhaps best illustrated by UML system and state diagrams). Having wondered why, I have a couple ideas. Perhaps they don't really know enough about visual modeling to attack it. More likely, they like modeling but don't like the languages available to them for implementation. Assuming the later case, their models would likely have data, manipulators and flow modules; they just wouldn't appear to be so without the convenient naming schemes some of us are so familiar with. One nice result of OO is discoverability.

OO is neither a panacea nor a design disaster (in the general sense). It's another tool in a fairly crowded toolbox.

Bruce seems to feel that OO fails (or at least falls short) for concurrency which is true to a degree. Large mutexed methods in any language are a major problem. Doesn't that mean we should continue to strive toward smaller objects and methods (finer grain) where ever possible? That works until we're stuck creating (and eventually destroying) twenty objects for a simple operation. Stack objects in C++ make this a heck of a lot better from a performance viewpoint, and led to flyweight utility functions. But that's the only place it works that way. So perhaps the argument is that OO isn't agnostic across languages? Possible, but I'm going to ignore that for now.

The failing I see today in the static OO languages are generics. Although I haven't used JDK 5.0 yet, I've been reading about it quite a bit. As a long time abuser of C++ templates, I was dismayed because it's the same crummy syntax. Unlike the scripting languages, which allow for useful (if often simple) generic functions, the proper tuning and completely unreadable nature of generic functions (long term) in static languages OO sucks wind. Our custom algorithms are the parts of our applications most in need concurrency help (not the messaging semantics).

I'm not about to abandon OO, even if I envy those who can fall back to using a DB for everything but it's an interesting perspective.