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)
|*Everything* is much better in theory than in practice.—Michael Gupton |
"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#)
|Purpose far outweighs some abstract notion of perfection.—Nikolaos Vogiatzis |
"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++)