OOP Is Much Better in Theory Than in Practice

ike many ideas that sound good in theory but are clumsy in practice, object-oriented programming (OOP) offers benefits only in a specialized context—namely, group programming. And even in that circumstance the benefits are dubious, though the proponents of OOP would have you believe otherwise. Some shops claim OOP success, but many I've spoken with are still "working on it." Still trying to get OOP right after ten years? Something strange is going on here.

Certainly for the great majority of programmers—amateurs working alone to create programs such as a quick sales tax utility for a small business or a geography quiz for Junior—the machinery of OOP is almost always far more trouble than it's worth. OOP just introduces an unnecessary layer of complexity to procedure-oriented design. That's why very few programming books I've read use OOP techniques (classes, etc.) in their code examples. The examples are written as functions, not as methods within objects. Programming books are trying to teach programming—not the primarily clerical and taxonomic essence of OOP. Those few books that do superimpose the OOP mechanisms on their code are, not surprisingly, teaching about the mysteries of OOP itself.

Of course professional gang programming has specialized requirements. Chief among them is that the programmers don't step on each other's toes. For instance, a friend who programs for one of the world's largest software companies told me he knows precisely what he'll be working on in one year. Obviously, OOP makes sense in such a bureaucratic system because it needs to be intensely clerical. Helping to manage large-scale, complex programming jobs like the one in which my friend is involved is the primary value of OOP. It's a clerical system with some built-in security features. In my view, confusing OOP with programming is a mistake. OOP is to writing a program what going through airport security is to flying.

Editor's Note: DevX is pleased to consider rebuttals and related commentaries in response to any published opinion. Publication is considered on a case-by-case basis. Please email the editor at gkunene@jupitermedia.com for more information.

Contradiction Leads to Confusion
Consider the profound contradiction between the OOP practices of encapsulation and inheritance. To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same programmers to inherit, modify, and reuse this code that they cannot see—they see what goes in and what comes out, but they must remain ignorant of what’s going on inside. In effect, a programmer with no knowledge of the specific inner workings of your encapsulated class is asked to reuse it and modify its members. True, OOP includes features to help deal with this problem, but why does OOP generate problems it must then deal with later?

Why does OOP generate problems it must then deal with later?

All this leads to the familiar granularity paradox in OOP: should you create only extremely small and simple classes for stability (some computer science professors say yes), or should you make them large and abstract for flexibility (other professors say yes). Which is it?

A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP—often by simply copying and pasting. There's no need to superimpose some elaborate structure of interacting, instantiated objects, with all the messaging and fragility that it introduces into a program. Further, most programming is done by individuals. Hiding code from oneself just seems weird. Obviously, some kind of structure must be imposed on people programming together in groups, but is OOP—with all its baggage and inefficiency—the right solution?