Don’t Look for Grisgris

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 they 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 virtures 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.

3 thoughts on “Don’t Look for Grisgris

  1. I mostly agree with what you said, but I think this also a matter of our own (or our brains’) preference to use object-oriented approach or not. Some people “just” find it natural, while the other “just” find it unnatural. Maybe my brain thinks in Objectese and other peoples’ brains think in Structurese 🙂 Some like to have code organized by functionality while other want to clearly separate algorithms and data.

    Unless I’m writing a 5-liner-script, I always use objects. But I can imagine that some people will find it too complex for such a small task. I know from my experience that a “use-once-and-throw-away tool” may stick with me for months, so I always choose to write it well from start (even if I’m in a hurry). But it’s my experience and my preference. Other people may have other mileage or they just prefer to write it quick and dirty and maybe tidy it later.

  2. Interesting observation about object thinking being natural for some and unnatural for others. I mostly agree with you. I remember at Tektronix, when we were teaching object thinking (even for C++ programmers) we had them spend some time programming in Smalltalk where everything was an object. That way they got immersed in that style of thinking. When I first started programming in Smalltalk I found myself “translating” everything to my procedural way of thinking (method = function, message ~= function cal)…but that didn’t help, it only seemed to get in the way. It was only when something relaxed in my brain (the same feeling I had when I learned to let go of control and let recursive algorithms work without having to know everything on the stack, actually) that I started to let go of wanting to know all the details and the power of object thinking really got into my head. But it took some time.

    I think that different ways of thinking do take time to soak in. And one way to speed up that soak time is to completely immerse yourself in that way of thinking.

  3. Regarding the claim that OOP makes code more maintainable, I have yet to see a realistic example. Well, I take that back. I have seen reasonably convincing examples in systems software, but not for business applications. The nature and patterns of changes in biz apps just seem different than in systems software. Mr. Mansfield rightfully asks for reference demonstration/application(s) that at least attempt to demonstrate these claims with code instead of anecdotes for biz apps.

Leave a Reply

Your email address will not be published. Required fields are marked *