The Object Oriented Hype

bedel231 sent us a fairly lengthy and detailed article discussing the hype surrounding Object Oriented Programming and tries to claim that a lot of things taken for granted are mythical. Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points. Regardless of your stance on the issue, it's worth a read.

common misconception

one common misconception is that one can not do object oriented design in C, or any language that isn't approved by the OOP zealots. this is just not true, while it may be more natural to write a good object oriented design in C++, Java or Smalltalk. it can also be done in C or BASIC.

one can create objects in C by creating a structure, then passing that structure to every method that performs on that structure. a common use could be something like this.

struct window_t win;
window_init(&win)
window_draw(&win);
window_destroy(&win);

it is also possible to perform polymorphism and inheritance with function pointers and other techniques.

-Jon

Re:word games

Many OO debaters often stretch the meanings of the the big three (poly, inher, encap) to mean whatever they want them to mean. ... "Encapsulation" is such a vague, watered-down word that it can mean just about anything you want it to.

Just because many people don't understand the definition does not mean that the definition is vague or watered-down.

Anything that is "not at the right spot when you need it" can be blamed on "lack of encapsulation".

I would more likely blame lack of coherent design. But lack of encapsulation can result from the programmer hacking his way around the encapsulation to solve the problem.

Note that many of the goals of OO can be achieved in ways that are not necessarily OOP.

Agreed.

--

Re:common misconception

It's also true that you can do good object oriened design with a Turing Machine, implemented in the Game of Life, composed of a million midgets wearing reversible parkas, which is directed from above by an Elvis impersonator in a hot air ballon shaped like a guitar.

You signed an NDA on that design. Expect a call from our lawyers.

--

The real benefits

The article is vapid since it addresses a collection of OOP myths that don't cover the real benefits, and secondly comletely ignores the practical reality that for most people the OOP/procedural choice is C/C++ choice, and that C++ has many features (such as constructors/deconstructors) that while not necessary for OOP, are huge benefits.


Myth: OOP is a proven general-purpose technique
Myth: OOP models the real world better
Myth: OOP makes programming more visual
Myth: OOP makes programming easier and faster
Myth: OOP eliminates the complexity of "case" or "switch" statements
Myth: Inheritance increases reuse
Myth: Most things fit nicely into hierarchical taxonomies
Myth: Self-handling nouns are more important than self-handling verbs
Myth: Only OOP has automatic garbage collection
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data
Myth: OODBMS are overall faster than RDBMS
Myth: C is the best procedural can get
Myth: Implementation changes significantly more often than interfaces
Myth: Procedural/Relational ties field types and sizes to the code more
Myth: Procedural/Relational programs cannot "factor" as well


Classic OOP features such as inheritence may generally be over-hyped, but specific cases such as polymorphism are very useful (even if there are ways of doing the same thing in languages such as C that were not designed for OOP).

Some of the major benefit of OOP, and specifically C++'s objects, are:

o It is a clean module packaging mechanism that encourages cleaner interfaces between modules

o It encourages opaque data interfaces (method access vs public access) which results in less bugs

o It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors.

o The self-containedness of objects does make code reuse simpler and less bug prone.

etc, etc.

The guy who wrote the article (and the esteemed Mr. Taco) appear not to have much hands on experience writing OO code.

Myth...

Myth: Implementation changes significantly more often than interfaces

This is the most stingingly correct point, in my opinion. In fact, in my experience, they change equally often at best. And in cases where code is actually meant to be reused - something which, by the way, some of my smartest friends have told me, after no small amount of experience over the years, never actually happens - its the interface that often proves more likely to need modification...

Re:I tend to agree with the author..

OOP (IMHO -- I'm crazy for the acronyms today), is just a fad. Like structured programming was before it.. Unfortunately a lot of these companies today fall into "trendy" programming methodologies.

Structured programming a fad? OOP a fad? A rather long-lived fad then! Software developers have been using structured programming techniques and OO design for years, and will continue to do so.

Personally, I believe you should program using the style you're most comfortable and familiar with. If you're trying to fit a mold it will slow you down.

That's fine if you're working on a small project with maybe one developer. But if you had 30+ developers using their own techniques and styles on a large project (like the >1MLOC project I've been working on for the last 5 years) you'll end up with an unmaintainable mess. If everyone conforms to a standard methodology and style then at least you can maintain each other's code.

This is one of the differences between software ENGINEERING and code that's been congealed instead of designed. Software engineering should result in a robust and maintainable system. Letting every programmer go off and do their own thing as you advocate leads to the truth in the phrase "If builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization!" It sounds nice to let the programmer go off and just write in their own style using their own unique design techniques. But it's terribly naive and unrealistic in the real world.

Article Only Proves Low Education Level

It seems our skeptical OOP critic is pulling graphs from nowhere and making logical flaws left and right. Refuting his article is quite easy, but there is no doubt in my mind that he would not accept the refutation. His failure is that he refuses to accept the absolute need for abstraction.

I work in a software company, and our product takes up no less than 300 MB of code. Even in the most well-organized non-OOP code, our software would be impossible to debug or even build, because we would need to go through hundreds of lines of code. In addition, reusability would be hurt, since even though the functions would be there, minor changes in the arguments might make the entire function worthless.

The author's example using People and Taxes is particularly striking. He suggests that an object oriented approach would create a person object and a tax object, set their attributes, and run the T.CalcTax method on Person P, while a procedural approach would just feed the relevant parameters to a function. I wonder if the author has ever actually filled out the 1040 Personal Income Tax Return Form [fedworld.gov]. The easy version has 70 entries, and while some are calculations, others are references to other, much bigger, forms! Keeping track of all these variables without some structure to hold them all is just stupid. Object orientation is necessary when code hits a level of complexity where several people, or several hundred, are simultaneously working on a project. The "black box" approach allows for greater flexibility and optimization, since a code change will be transparent to the objects around it.

Another thing to consider, although I know CmdrTaco would berate me for even mentioning it, is the expansion of OOP provided by Java. The Interface in Java allows you to specify several functions, abstractly, that are required for a class to implement the Interface. The implementation of these functions is class-specific: for example, all clothes implement the Wearable interface, but you would not want underwear and shoes to have the same implementation of Wear(). However, in Java, you may specify a function to take a Wearable object, and not need to specify any further. This abstraction level is why OOP does, in fact, better model the real world.

In conclusion, the rantings of a PASCAL junkie should not constitute a Slashdot article. Anyone who has coded in procedural and OO languages should see the extreme idiocy of the article within milliseconds. On the other hand, Perl powers Slashdot, so I guess this is the place for the procedural approach to have its message heard. In fact, Slashdot totally vindicates the article: its non-OOP approach is fast, effective, efficient, and easy-to-understand. Highly scalable and expandable as well. I especially like Slash.pm (aka THE BEAST) and the my_conf{shit} variable. I'm sure the non-OOP approach will really take off once everyone switches over from C++/Java to Perl.

Re:Anonymous hack berates OOP

Absolutely. Let's look at OOP vs Communism:

Classes: Communism - adamantly against. OOP: For, not merely for, but in favour of more classes than you could possibly imagine.

Inheretance: Communism - opposed to. Inhereted property regarded as a prop for the aristocracy. OOP: Treats the concept with a reverence not known even amongst the Kennedies and Rockafellas of this world. Encourages, aids, and supports.

Property: Communism - private property treated as an ambonination. OOP: Supports, allows objects to have whatever properties they want, and decide for themselves what is public and what is private.

Objects: Communism - usually on the side opposing the objectivation of anyone, women, minorities, etc. Even cynically, prefers to deal with people as an anonymous mass rather than discrete objects. OOP: Pro-objectification. Treats everything and everyone as objects.

I think it's pretty obvious that our OOP berater has no idea what sie's talking about. That said, most communists I know feel the need to talk in wordy jargon to demonstrate their superior intellects. With OOP programmers making sure they use everything from 'abstraction' to 'polymorphism' in every other sentence, I can see why the author might have been confused...
--

There's no magic bullet...

The hype of OOP is that it's a magic bullet that does all your thinking for you and that all you have to do to write a completely new program is derive a new class and change a couple of lines. This is, in a word, crap.

Thing is, if you can't do design in procedural code, OO's not going to buy you anything. Projets that buy into the aforementioned hype will fail. A company throwing OO at a projet without investing in training of it programmers will see the project fail. There are some simple OO mistakes that you see new programmers or procedural programmers who've never done OO before. Deriving everything from everything else. Using inheritance for everything. Habits that it's hard to break them of because nobody realizes that they're bad habits.

Do a bit of research though, and you can find ways to be very productive using OO. If the designs are good, it does actually get easier. Buy "Design Patterns" and poke around in the various OO language netnews archives for little nuggets of wisdom and you will find your object designs improving immensely. Read about STL and use well designed toolkits like gtkmm and you'll start to realize benefits from using Object Oriented programming.

Wrong

I think you need to look at the definition of an "Object Oriented" language. You'll see that to be OO a language must support certain things like inheritance, polymorphism, run time binding (dynamic binding) and many other fun things that you can't do in procedural languages. C doesn't support any of those.

Of course it "supports" them. It's just not as easy as it is in other languages. As has been pointed out before, creative use of function pointers in C can be used to implement polymorphism and "dynamic binding."

Think about it a minute. What does a C++ compiler do? It translates the (high-level) C++ code to (low-level) assembly code. Are you somehow suggesting that there is no way that the generated assembly code can implement inheritance and polymorphism because no assembly language "supports any of those?" If so, how is it that C++ programs are able to compile, link, and execute? The original C++ compiler, cfront, generated C code as output from the input C++ code. Surely the output C code was no less "object-oriented" than the C++ code it was generated from.

You can write object-oriented code in nearly any language. The difference is how much language-level support for OO is provided. Just because you can't write "virual void myFunc()" in C doesn't mean you can't generate the same behavior.

Re:Examples?

OO does not bring benefits for all projects. OO does not always bring short term benefits. Where OO excels is maintainability and understandability, as well as distribution of labor for a medium or large scale project. A 15 hour project is nothing. Worst case if you need to expand or maintain that project, you waste another 15 hours. A large scale multiple year project, however, truly benefits from an OO approach.

If implemented with discipline and knowledge, an OO project is better maintained than a procedural one. However, I would take a disciplined procedural project over a messy OO project. The overall guiding point is rigorous software engineering, and OO provides some language level discipline, while procedural programming provides nothing at the language level. If a good process is followed, though, language level support is just convenient fluff.

Russell

How can OO be a "fad" if ...

... it's been around (and used successfully) for over fifteen years?

As Jim Coplien has pointed out, OO (objected oriented programming / design / analysis) is older today than "structured" programming / design / analysis was when OO first burst upon the scene. (The structured movement first got some serious press in the mid to late 1960s; the classic book by Dahl, Dijkstra, and Hoare was published in 1972. OO started no later than Simula-67 and Smalltalk-72, and first gathered mainstream attention in the 1980 - 1982 timeframe. The first OOPSLA conference was in 1986.)

Yes, some snake-oil salesmen overhype OO ... or whatever buzzword they can apply to their product. Surprise.

No, OO is not a panacea. It's not even always the right tool to apply to a particular design or programming problem. (Coplien's recent book, Multi-Paradigm Design for C++ [fatbrain.com], is a tough but worthwhile read that addresses this issue.)

You may dislike a particular language that supports OO (Smalltalk, C++, Java, even Perl) but find the paradigm worthwhile in some other language.

For comparison, compare with this message in Risks Digest [ncl.ac.uk]: "The structured programming revolution is a real bad idea that has been significantly holding back progress for years.... Have there been any double blind studies which unambiguously show that the kind of programs that structured programming partisans enjoy are really more maintainable than some other kind of program? I've heard lots of testimonials, but no real evidence." Sound kind of familiar? (Heh.) --PSRC

Re:Author is a USENET troll/pest

Ha! Man, he's probably trolling around here, too. I wonder what his slashdot ID is? Probably the same one who submitted the story ;)

Wow. I think /. has been seriously trolled this time.

Re:I tend to agree with the author..

I don't think its a fad. Structured programming is still the model we use, even when using it within object-oriented programming.

The guy who wrote the article missed one of the most important aspects of OO, and that's _interface_ inheritance. Interface inheritance is _NOT_ subtyping, and is vastly more flexible and usable than subtyping, which seemed to be one of his big gripes. If you want to know more about interface inheritance, look at my page at

http://members.wri.com/johnnyb/comppapers/factor in ginheritance.html

I called them "feature factors" here.

People think in objects

Does OO make assumptions about human nature?

Actually it does. But it's a correct one.

One of the basic assumptions is that the human brain is built to think about the world in terms of things that have properties and behaviour. We can think in terms of procedures and execution flow as well, but we're not nearly as good at it.

Re:common misconception

If you add the methods to manipulate the structure (via function pointers if you're using C), then you have an object.

What do you think the "window_init", "window_draw", and "window_destroy" functions were? Just because these functions weren't formally defined as methods of the window_t object doesn't mean that they aren't methods. In the programmer's mind, they're methods, and that's what matters, in the end.