watch this  

the official mrchucho blog

OOP Considered Harmful

Posted 2005 Jan 20

This opinion piece at DevX is riddled with the strangest proclamations—disguised as dissertation on the utter failure of OOP. Here are some choice quotes:

object-oriented programming (OOP) offers benefits only in a specialized context—namely, group programming.

That’s the strangest (and most inaccurate) claim against OOP that I have ever read. I use OOP successfully in almost all of my projects… from the largest web app to the smallest Python-powered AIM bot!

With the possible exception of GUI components, I’ve never heard of an OOP success story that on close inspection demonstrated OOP’s efficiency.

What about frameworks like Cocoa? I would point to this immediately and enthusiastically as a successful OOP implementation (and not just the GUI portions)! A well-designed OOP framework is both efficient and powerful. Because of things like polymorphism and dynamic binding, I can use Cocoa classes as building blocks - rather than re-inventing the wheel. With encapsulation - which seems to be author’s biggest fear—I can focus on my application and leave the “plumbing” to the framework.

Further, most programming is done by individuals. Hiding code from oneself just seems weird.

Listen: you are not secreting it away… you are encapsulating an implementation detail that, once implemented, does not necessitate constant re-examination. Clearly, the author comes from the “I want to see every detail” camp—talk about inefficient!

A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP—often by simply copying and pasting.

I have to give him this one: he has discovered the fabled 100% Reusability! Seriously, even junior programmers know the answer to this one! Say it with me: “Now you have to change it in many places instead of one.”

Encapsulation, too, is a noble goal in theory: you’ve reached the Platonic ideal for a particular programming job, so you seal it off from any further modification.

Yes, but there is more: encapsulation allows code to be segmented. So, when modifications do occur, they can be limited to the encapsulated space—rather than effecting the user’s of said code. Encapsulation isn’t the end, it’s the means.

I think this piece suffers from a case of throwing the baby out with the bathwater. OOP is a powerful paradigm, but certainly one that is easy to abuse. And, unfortunately, more often than not, it is. But, I think we all know: With great power, there must also come great responsibility.

OOP, if properly implemented and not over-applied, can lead to a startling succinctness. Certainly more lucid than the reams of comments and duplicated code that tend to accompany procedural programs. In fact, I would argue that OOP more accurately models Natural Language than procedural programs.

The true thrust, in my opinion, of this article does not appear until the end: a rant against C++. It’s a shame that he seems to have con-fused the two. One would think that the rising popularity of languages like Ruby, Python and others would have caught the author’s attention—but they are strangely absent.

The author seems also to have neglected the notion that OOP and simplicity are not mutally exclusive. Again, it is difficult to perceive the author’s ulterior motive. Likewise, he doesn’t seem to present a plausible alternative—except, perhaps, for the implicit hark back to the Glory Days of Procedural Programming.

Update: seems I’m not the only who is shaking his head at Mr. Mansfield.

Responses to "OOP Considered Harmful"

Tom Minderson

2006 May 10 at 21:26

Regarding OOP frameworks, there are procedural/relational frameworks also. Nobody has proven OOP frameworks better. Further, although I agree that OOP may work fairly well for low-level access to the outside world, it does not do very well for custom business modeling. This is because OO is not based on Set Theory. Sets can handle orthogonal attributes/factors better than trees, and offer more discipline than “navigational pointer” structures that are called “aggregation” and “composition” in the OO world. Sets are powerful yet clean.

Regarding reuse, there are many ways to get reuse without OOP and without copy-and-paste. Functions are one example. The binding of behavior and data that OOP brags about is less practical when dealing with info that must be shared to solve the domain. Encapsulation falters here.

Regarding “encapsulation allows code to be segmented. So, when modifications do occur, they can be limited to the encapsulated space—rather than effecting the user’s of said code”. In the real world things are not so easily isolatable. Multiple tasks often need the same info. If each object must handle all possible external needs, it ends up re-inventing a query language the long, hard-wired, verbose way.

Regarding “In fact, I would argue that OOP more accurately models Natural Language than procedural programs.” For one, I am not sure modeling natural language is a decent goal. English sucks. Second, this points out that the benefits may be a personal preference. I won’t tell you how to think, but please don’t extrapolate your preferences onto others. If OOP is truly objectively better, where is the code-inspect-able proof? If it is subjective, then Mansfield has a right to complain about being force-fed. Besides, I would pit Set Theory against OOP any day in a real test.

Comments are now closed.
atom rss