he recent DevX editorial “OOP Is Much Better in Theory Than in Practice” by Richard Mansfield has caused quite a stir among our audience. The strong response revealed contrasting viewpoints about the effectiveness of object-oriented programming. DevX culled through the flood of e-mail to present the best and most representative excerpts.
The following sections highlight Mansfield’s most controversial assertions and what DevX readers had to say about them. Each excerpt includes the respondent’s occupation and language of choice (in parenthesis).
For many programmers, OOP is almost always far more trouble than it’s worth.
“There’s always this assumption that OOP is somehow superior, and now all modern languages are striving to become OOP just to compete, even when they weren’t conceived to be (VB, Perl, etc.). Which is bothersome, because most of the programming I do doesn’t require rigorous OOP features like inheritance.”—Tom Dierickx, data analyst (Perl and VB)
“In real-world applications where database designs are constantly changing and evolving, it makes little sense to embed data in an object with the methods. I also find that loading data into objects really kills performance where CPU cycles are precious.”—Bob Itami, environmental planning and management (Visual Basic)
“I have experienced the religion of OOP in the avionics, the financial, and the telecom industries. They are just rewriting their systems in C++ or Java and expecting them to be the silver bullet of reuse and maintainability. One group uses Rational Rose to generate the code—talk about a confusing system!”—Todd A. Sorensen, aerospace software engineer (VB and Ada)
“One reason I originally got into this business was that I am basically lazy and I could get the computer to do the work for me. It seems the OO approach steps back from that and lets you do the work.”—A manager of applications development (PowerBuilder and VB6) who preferred to remain anonymous
“I have been writing software for 20 years and still haven’t found a good use for some of the elaborate requirements that OOP brings to the table. Programming buzzwords and techniques come out like new age seminars—a new panacea that really is a waste of time.”—Matthew Rover, owner of an upcoming software company (C#)
“Many of the complaints against OOP being hard to do correctly are really not about the shortcomings of OOP. They’re about the difficulty inherent in engineering good software. A large part of what OOP does is to automate the things that programmers were already doing with strictly procedural languages.
*Everything* is much better in theory than in Practice.”—Michael Gupton, programmer (mostly C#)
The primary value of OOP is its clerical features.
“Most software is too complex to manage without OOP. All of the components, classes, concepts, tools—mostly OOP-based.”—An author and software architect (VB.NET) who preferred to remain anonymous
“I loved this article, primarily because it demonstrates that purpose far outweighs some abstract notion of perfection. The right machine, with the right operating system, using the right development language for the job at hand is what counts.”—Nikolaos Vogiatzis, PhD Candidate (C/C++/MC++.NET)
“I have found that the abstractions that can be created through OOP make the design, construction, and maintenance of a system much easier. I find it ironic that [Mansfield] points to .NET, the most object-oriented programming environment from Microsoft, filled to the brim with OOP concepts, during his assault on OOP.”—Ethan Roberts, software developer (C#)
“While OOP is not the answer to everything, it has certainly advanced the state of the art. OOP (when used with good OOD) is a matter of organization and bookkeeping. What [Mansfield] missed is that it’s a good thing. It makes the code more maintainable and therefore, over the whole life cycle, cheaper.”—George Hahn, software engineer (C++)
The OOP practices of encapsulation and inheritance contradict each other.
“What contradiction? The guy who puts the ‘car engine’ objects together at the Pontiac plant shouldn’t have to care about how the person who made the ‘car piston’ objects achieved the result. He just wants to believe that it was properly made and can be reliably used.”—David Burne, contract analyst/programmer (VB.NET, C#.NET)
“The author seems to think that encapsulation means that the CODE is hidden from others, when in fact the items encapsulated are only protected during execution. Nothing in Visual Studio prevents either seeing the encapsulated stuff nor in fact editing it.”—Richard Weis, information technology executive (C#)
“OOP aims for [almost decomposable]: a layer of encapsulation bigger than the procedure and smaller than the file. That does seem a good idea.”—Peter Mott, independent developer (Python)
“I really don’t care how the WindowsRegistryReader class I was handed works. I just know that when I call the GetKeyValue method it gives me what I want.”—Jim DeMarco, director of application development (VB6 and VB/ASP.NET)
“There seems to be an inherent contradiction in purpose in using both encapsulation and inheritance. Methods are first hidden in how they are coded but may be later modified in how they work for a given class (isn’t the whole ‘virtual void somemethod()’ supposed to allow for an intuitive notion of how somemethod() will work in different circumstances or with different data? At least in C++?)”—John Armstrong, engineering consultant (Labview and C/C++)
One can reuse code without OOP—often by simply copying and pasting.
“Doesn’t really take saying for any professional developer, but this approach means that when you find a bug in code, you have to fix it in a dozen places, instead of once.”— Anthony Glenwright, product development manager (.NET languages)
“Richard can’t seem to grasp the obvious—that you leverage through reuse. You take all the M$ controls and subclass them into your own framework version. This way, you can add functionality to the control, and when M$ changes them, our classes don’t break.”—Stephen Russell, programmer (C#)
Efficiency is the stated goal of C-style languages and OOP, but the result is too often the opposite.
“I’ve been programming for a good few years myself and have often wondered why many programmers now feel that just because they’ve used OOP techniques that their programming must be good. They don’t think about the fact that procedural code performing the same function might be half the size and complexity.”—Dave King, senior systems developer (VB)
“Object-oriented design is often the most natural approach to a problem. If one chooses to implement that design using an OOP language is another matter.”—Matthias Kronenberger, software developer/computer scientist (C++)
“I have adopted some OO techniques with success, especially those that allow real reusability. However, the verboseness, seriously diminished transparency, and general unwieldiness of the .NET languages are an obstacle to rapid development.” —A database developer/consultant (VB6) who preferred to remain anonymous
“Many developers practice a design style that is more ‘Class Oriented Programming’ than ‘Object Oriented Programming.’ They don’t use any sample business data to develop their object model and data flows. Instead, they start designing elaborate class structures without trying to prove that they are capable of processing the actual data that they will be required to handle.”—Phil Corcoran, software engineer (Java)
“A large part of the problem—especially for smaller projects—lies in the languages used, rather than the overall OOP paradigm. Languages like C++, Visual Basic, and Java force a layer of extra structure and obfuscation on the programmer, which, strictly speaking, has nothing to do with the OOP paradigm.”—Jay Osako, freelance software developer, primarily Web (Scheme, recently Python)
“It is silly to rewrite programs from VB6 to .NET (or Java) simply to stay current, but alas, that’s what we’ve been doing since BASIC made its appearance. We’re glad for the improvements, but not the added complexity that this last round of languages has introduced.
My biggest problem with OOP is its lack of integration with the current crop of databases. The supposed need for an OOP to SQL mapping layer (object-relational mapping) is absurd.”—Stan Coplan, president of a software and multimedia development company (VB.NET, ASP. NET, VB6, C#, Java)
“Simply put: more advanced data structures (e.g., deques, graphs, double linked lists), which improve efficiency and runtime, are most effectively achieved through OOP.”—Dave Russell, software engineer (Java)
“I think that C++ has tainted the whole concept [of OOP languages]. This one language is so big and so complex that no one in their right mind would use it for learning OOP. Unfortunately, it’s also massively dominant. Java’s an improvement, but is still way too complicated.”—Dr. Alun J. Carr, Mechanical Engineering Dept., University College Dublin (Tcl/Tk)
“I have observed many, many wasted programmer months, failed projects, and failed companies due to way too much OOP design time and too many layers [and] objects, which just make the systems hard to program, hard to learn, and slower.”—Jerry Howard, programmer/consultant (C#)
“The most attractive benefit of OOP is in maintenance, not in efficiency of initial implementation. OOP requires greater effort in the requirements, analysis, and high-level or low-level software design stages. Sadly, the vast majority of programmers don’t design or design very poorly. I believe that explains the crummy results for OOP.”—Mark Bullock, software QA analyst (Java)
I’ve begun to wonder whether OOP is simply the latest fad.
“I do not think that in our world of distributed computing OOP has a future at all. Within one computer it is perfect; but it is unacceptable for communication. Consumers process and interpret data the way they like, not the way producers want them to. That’s why OOP is going to gradually turn from a universal idea to a niche technology.”—Vlad Patryshev, software engineer (Java with generics)
“If you look at every standard library that has been added to ISO C++ in the past 10 years, you’ll see that classic OO is dead. Virtually all of these libraries are designed according to a different paradigm: generic programming. Get used to thinking in terms of templates, meta-functions, and generics. OO is dead; long live generic programming.”—Danny Kalev, independent software engineer (C++)
“OO has lasted too long and it [is] too widespread to be considered a ‘fad’. It may be ‘misused technology’, but that is a separate (and equally incorrect) argument.”—Matthew Roberts, PhD student and Lecturer (Haskell)