Gris-gris
African fetishes, charms or amulets.
Objects believed to have magical or spiritual powers to protect against evil or injury.

I received an email from a colleague pointing out a blistering critique of object technology in an article by Richard Mansfield, OOP Is Much Better in Theory Than in Practice, and a website devoted to defrocking object-oriented myths. The article starts out on this gloomy note and only gets more negative:

“Think object-orient programming (OOP) is the only way to go? You poor, misguided soul. Richard Mansfield contends that OOP is just the latest in a history of ideas that sound good in theory but are clumsy in practice.”

My colleague found this rant rather depressing. He has assumed for years that modern systems are ideally coded using OOAD—but still has struggled to make it happen in his own projects. He asked, what do I think of this kind of criticism?

Here’s my take. Any one who raises questions and concerns is good to listen to. There certainly initially was a lot of hype around objects. In the early days it was oversold. On the other hand, many of Mansfield’s comments remind me of someone who likes take broad swipes at something just for argument’s sake as well as someone who tweaks things for database performance. For him, objects get in the way. He’d much prefer to build software machinery optimized for relational database access. Reminds me of the classic ACM Article by Donald Knuth extolling the virtues of GOTO statements. GOTOs are useful sometimes. Objects, in my experience are even more useful—but not universally so. I know lots of people who have benefited from doing the hard work of creating a design with reusable classes with planned variations. Creating a model of interacting objects is hard intellectual work. Writing piles of code with cut-and-paste reuse is easier. It just is harder to maintain. I also know people who don’t see much benefit of objects because most of the code they write simply shovels data to and from a database with little behavior other than validity checks in between. While they may use objects to create GUIs and get results back from the database, they rarely invent objects of their own. And unfortunately, object programming languages still don’t co-exist very neatly with relational technology.

The value of object programming and design is apparent when you have significant behavior in your application and you create a model of interacting objects that does some significant work. Sure, you don’t need objects, just like you don’t need high level programming languages. But objects can sure come in handy. To discount the benefits of object-oriented designs simply because people don’t create good designs using them (another one of those correlation=cause false arguments in this anti-object writing) isn’t a rational argument. That’s like saying diets don’t work because fat people diet! There are also tangible benefits to developers who leverage extensive class libraries to build complex systems. I would hate to have to build all the complex software we do today without them!

I thanked my colleague for pointing me to this website and article. I’m going to give them a more careful reading which will probably result in some blog entries, if nothing else. Untangling any truth in a rant from fallacy is always good practice. But at the end of the day, we shouldn’t be looking for grisgris to be universally applied with blind faith to ward off all software ills. Instead we should be looking for solutions that work well for a given situation. I find objects a pretty good tool for a wide class of problems. In my own modeling and design over the last two years I’ve also looked at creating solutions using declarative approaches and seen how rule engines and objects mix (not very well unless you are very skilled at abstracting and writing generic rules with lots of meta-context). The value of objects hasn’t dimmed; my toolkit has simply expanded.