watch this  

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.