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.

Talk about flamebait...

The article is topped off with a gif image tagged "OOP Stinks!". That should give you a good insight into the level of discourse that follows.

Of course, the author absolves himself from all responsibility for having to present anything more than an emotion-filled diatribe by stating early on:

Disclaimer: not all myths discussed are necessarily shared by all or even most OO proponents. They are based on "common notions" found in the business and programming world as I have observed them. I am making no claims as to the frequency of beliefs in the myths. My frequency of encounter may differ from yours. Discussing myths is not the same as "punching a straw-man", which some OO proponents claim I am doing by mentioning myths.

So... his article is based on debunking "OOP Myths", which he states are not "necessarily shared by all or even most OO proponents." He repeatedly fails to back up any of his points with citations or references (and at one point, actually states "Sorry, we accidentally lost the references.") Instead, he justifies his arguments by making blanket statements like "Many OO books and even some OO fans suggest that OO only shines under fairly ideal conditions." Which OO books? "Some" OO "fans"? (Remember the disclaimer - not neccesarily all or even most OO proponents...)

Finally, some of his commonly (or not-so-commonly - take a look at that disclaimer, again) believed OOP myths are outrageous to the point of being silly... OOP eliminated the need for case or switch statements? OOP makes programming more visual? Only OOP has automatic garbage collection? Components can only be built with OOP? Only Only OO databases can store large, multimedia data? Who, exactly, does believe these myths? PHBs? Certainly not anyone with a CS education or decent amount of programming experience.

The best thing I can say about this article is that I think the author has a few good points and compelling arguments that are, unfortunately, lost amid the noise and confusion of unsubstantiated facts. If you can read it through and keep from grimacing in pain as OOP is compared to communism and the lack of research in non-OOP languages is decried, you might be able to find an idea or two that will reward you for the effort.

In the tiger compiler book

the quote on top of the object oriented langages chapter was something like:

"object: to feel distate for something"

I laughed my ass off (even if I do OO programming since 1991).,

Cheers,

--fred

Good objects are a lot of work

I work in C and Python. In C, I occasionally do a tiny amount of C polymorphism using function pointers, but it's infrequent. Python's OO model is very easy to deal with, but I find that prematurely OO-ing my code is as bad as premature optimization. If I'm really lucky, my objects will be useful for some later project. This is by no means guaranteed.

Objects are great where they work, and where you have the time and experience to tune them to perfection. The Python libraries are full of beautifully crafted, wonderfully useful object definitions. But that investment is large, and in many cases, doesn't make sense for the purpose at hand. And there are problem domains for which objects simply aren't the natural description.

The OO people say that the wrong way to reuse code is the cut-paste-tweak method, because then you have two diverging copies floating around. In a perfect world everything might be in a source code repository and I could submit a change rather than spawn a private tweak. But change submissions mean bureaucracy, if I'm working with other people. If my tweak will never see public use, the overhead is an unnecessary diversion.

The cited geocities page makes noise about table-oriented programming. I remember hearing similar things in the past, stuff like "Put the intelligence in your data and keep your code simple". I would have liked to see a better description of TOP, perhaps a few pointers to tutorials. The guy's own descriptions are pretty useless for quickly grokking his point. Maybe he's only preaching to the database crowd, and I'm not supposed to get it.

A cop-out?

Disclaimer: not all myths discussed are necessarily shared by all or even most OO proponents. They are based on "common notions" found in the business and programming world as I have observed them. I am making no claims as to the frequency of beliefs in the myths. My frequency of encounter may differ from yours. Discussing myths is not the same as "punching a straw-man", which some OO proponents claim I am doing by mentioning myths.

So... this is based on his experiences, without research? He has based this piece of writing on merely his viewpoint? Surely, if any technical critic wishes to be taken seriously, he should back his work up with proper figures and research, rather than "myths".

Communism also looked good in theory, but its base assumptions about human nature were flat wrong!

Okay... he's comparing OO with Communism? I don't see the connection. Does OO make assumptions about human nature?

This seems far too much like a rant, backed up with a few web pages... I would not take this seriously.

Re:Another reason ...

How far is "... a while back while working on an unnamed CPU project..."? If you are talking 5+ years, or even 3+ years, than you data is out of date as today's compilers are much more efficient about optimizing C++ code.

Re:common misconception

Sure OOP is a design technique not an attribute of a language (although some make it easier than others), but your example is bogus.

A data structure is a structure, not an object.

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

Tell us something we don't already know...

Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points.

Taco,
Some of us remember what slashcode [slashcode.com] looked like before pudge and friends started cleaning it up.

Not only are you opposed to OOP, but you don't seem to be terrible wild about structured programming either. Nor do you give readibility and maintainability the time of day. Your relationship with elegant code is in the "distant admiration" category and you seem to consider sobriety an impediment to productivity.

Not that I disagree with you on any of these points, I just wanted to mention that we allready know about them.
--Shoeboy

Re:Author is a USENET troll/pest

Actually, you can just look at his pages to find gems like this:

Actually, most GUI application programmers almost never see the code structure that makes up their screens. They simply click on a screen item, an event selection box comes up (Events like: on_click, on_exit, on_keyboard, etc.), and then a "code snippet" box comes up to edit the event code. Whether that event code is in a method or subroutine does not matter that much to the programmer. If you changed the generated code implementation from OOP to procedural and/or tables, the programmer may never even know the difference.

This is not a programer!

Poor criticism

The linked article seems to have more to do with the "silver bullet" mentality than OOP specifically. Anybody worth listening to will tell you that it's just as easy to screw up a OOP project as it is a procedural project. Really, has anybody used "it's object-oriented" as a selling point since 1989 or so?

In general, the criticism contained in the article is poorly founded. The author uses some nice charts, but has no citiations for them. For instance:

The problem is that building generic abstract modules (intended for reuse in later projects) requires roughly three times the effort as a project-dedicated (regular) module. Although no references will be given here, this figure is fairly widely accepted in the industry.

Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers.

Some of the things he calls out apply equally to procedural languages, such as:

When a new language fad replaces OOP, how do you convert legacy Java objects into Zamma-2008 objects?

When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh?

He makes some good points about measuring the effects of change (everybody should do that!) but I don't think this really strikes a death blow to OOP.

Neutron

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.

That isn't saying it's a good a idea.
--
Bush's assertion: there ought to be limits to freedom

Re:common misconception

I agree.

OO is just a handy way of structuring large systems for maintainability. It is extremely useful for what it does, but isn't magic.

People who dismiss OO out of hand are making the same mistake as zealots who insist that it must be used for everything by rejecting a useful tool.

Structured programming, functional programming, OO etc are all extremely useful given the right problem domain. The skill is being able to look at a problem and pick the correct tool for the job. Rejecting, or choosing, something automatically can be a very good way to shoot yourself in the foot.

Re:reusability...

It has been a long time since I last posted to Slashdot. I can normally restrain myself, but this is just pure and absolute BS.

Properly implemented, code re-use can pay off immediately. I have worked in shops where every time we added a client, we needed a new copy of the code. Even though most of the processing was the same for the new client, we had to start out with a copy of the code. Code re-use would have bought us hundreds of thousands of dollars very quickly. (This did not ocurr at my current employer)

Properly implemented abstraction and OO along with iterative design can save a large amount of money very quickly. The key is to prototype your interfaces for the application you have in mind. Once you have done that, think of a completely unrelated use of the interface and test that. If you can handle 2 or 3 different uses, you have a good interface to start with. Rinse and repeat for the rest of your system.

People may question you immediately, however the minute somebody decides to change the system message transport from http to JMS, you should be able to convince them of the value of proper abstraction and code reuse, just change the transport class and you are done. I did this in a system where we did all of the work necessary to change the transport in less than 30 minutes. The consultant that had been working on the same problem for 3 months was absolutely amazed at quickly I made the change.

OOP is not a cure all, however its use along with proper abstraction can lead to large savings from code-reuse in a short time.

Mike
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Another reason ...

(for the record I first wrote smalltalk code in the 70's, I regularly code in C++ ...)

I'm a sometimes chip designer, sometimes programmer ... a while back while working on an unnamed CPU project I did some low level performance analysis on a number of well known programs (maybe even the browser you're using now) basicly we were taking very long instruction/data traces and then modelling them against various potential CPU pipeline/tlb/cache architectures - we were looking for things that would help guide us to a better architecture for our CPU.

I found that quite early on I could figure out which language something was coded in from the cooked numbers pretty easily - OO (ie C++) coded stuff always had a really sucky CPI (clocks per instruction - a measure of architectural efficiency that includes pipe breaks, stalls and cache misses) - I spent some time looking at this (since it seemed that C++ code would probably become more common in our CPU's lifetime) - basicly C++ code sucked because it took more icache hits (because the coding style encourages lots of subroutine calls which tend to spread over the cache more filling the I$ quickly) and it took more pipe breaks (also due to the subrotine calls and returns - it turned out that some code generators did stuff that broke CPU's return stack caches causing many more mispredicts) and finally virtual method dispatches (basicly load a pointer, save the pc on the stack and jump to the new pointer) tended to cause double pipe stalls that couldn't be predicted well at all even though these weren't done much they were a real killer (if you've one a bit of modern CPU architecture you learn that with long pipes you live or die on your branch predictor's hit rate - these were very bad news)

In short C++ and more genrally OO result in code and coding styles that tend to make code that makes modern CPU's run less efficiently.

Anyway - you often hear about 'efficiency of programmers' etc etc for OO - I thought I'd add a data point from the other end of the spectrum.

No Magic Bullet.

This article can be applied to any kind of programming paradigm. Basically, the author concludes that OOP isn't any good because some developers and managers aren't applying it correctly. Well, that's the case for procedural programming, declaritive, functional, etc. Yes, OOP will not solve the problem of rushed projects, poor management, or stupid programmers; neither will any other programming style though.

Programmers just need to be familiar with multiple programming practices and languages. Programmers need to know when just hammering out some _properly_ planned procedural code will fit the case better than some _properly_ planned OO code. There is no magic bullet and because of this, I think it's a bit pointless to say that one programming style is leaps and bounds better or worse than another.

I really wish the author had the confidence in the claims to actually site some hard facts and not some made up claims. Most of the article just seems like old rehashed FUD from the dawn of the OOP movement. The author mentions all of these failed business apps and blaims OOP for their problems. I guess IBM, Oracle, NASA, and some of the other big software shops are a bunch of idiots for doing any OOP. But of course this guy must be an expert on software design practices and that's why he has a Bell Labs URL.

Re:common misconception

(Go figure; that post just gave me my bonus back. Time to lose it again :)

Well, OOP should be used for things where the data structures resemble (in some way) real-world objects. For instance, games and other things that simulate physics can benefit from object-oriented design. Databases with dissimilar chunks of data might be easier to deal with using OOP. It may be helpful to represent other computers or programs as objects, in applications that require large amounts of intercommunication and response.

OOP essentially downplays procedural programming, but (at least I) tend to find many things procedural, which would have to be twisted up to fit into the OO paradigm. Anything that does an easily-definable process, such as most system utilities and so forth, is probably not suited for OOP. Back to games, I recently wrote a 'roguelike' game: although the code dealing with monsters and items was somewhat object-oriented, the game logic itself was procedural. Programs that primarily deal with large amounts of raw data should probably deal with it in a procedural rather than OO manner.

Author is a USENET troll/pest

For a long time now USENET groups like comp.object have been tormented by the author of that article with his constant barrage of FUD and inability to construct meaningful arguments. For an idea of what I'm talking about, check out his posting history [deja.com].

Herbie J.

Polymorphism

The author doesn't describe in depth what I consider one of the greatest advantages of object oriented programming -- polymorphism. Polymorphism is great because it allows you to invoke different methods for the same operation based on the derived class.

That makes more sense with a real example. I'm working on a set of classes that has a Stream abstraction. Derived classes must provide ways to do raw reads and writes, close the stream, and a few other things. (Preferably, they also provide some way to open the stream -- but that's not a virtual function.) The stream class itself provides buffered IO and some convenience functions for writing stuff in network order, a nice gets function, etc.

That allows me to have the same easy IO operations on top of many different kinds of streams:

• OSStream - what the operating system considers a stream. Can attach to a given fd, etc.
• FileStream - derived from OSStream, adds the ability to open a named object. (kind of a misnomer, could be a FIFO or whatever.)
• StreamSocket - also derived from OSStream, blends with a lot of socket functionality.
• PGLargeObjectStream - a PostgreSQL BLOB (binary large object). Basically, like a file but stored in a PostgreSQL database instead of using an inode. Handy because filesystems have limited number of inodes, not good for lots and lots of small files.
• SSLStream - a SSL connection, requires another open Stream (probably a StreamSocket) to connect.

Each one of these provides the same basic abilities -- reading/writing, seeking/telling (where applicable), closing, etc...but they do it in different ways. I need abstract read/write code so I can put shared higher-level code on top of it. Otherwise, I'd have to reimplement the higher-level code for each one. That would suck.

This doesn't even necessarily need an object-oriented language, just an OO concept. OpenSSL, for example, has a set of C functions that do a lot of the same things I'm talking about. It does it by providing a struct with function pointers...basically, a virtual function table. It's definitely not as pretty (I wish they would have just done it right and used C++) but it does work.

This is just one advantage of object-oriented programming, but I think it's a very significant one. Worthwhile by itself.

Re:My view

"If an object is data with functions, then I've been doing object-oriented programming all my life"

Generally when people talk about "OOP" they're referring to three general things you'll find in an OOP language:

1. Encapsulation: This is what you've been doing, by the sounds of it. Data, along with its associated functions, is grouped into an "object" (called a "class" in C++, I think its called an "object" in pascal, IIRC.) This is called "encapsulation", since both the data and functions are organized into a single entity. This grouping is very easy to do with any imperative language (as well as assembly) and follows traditional seperation of programs into "code" and "data" sections. OOP languages just bring the concept closer to the language by providing constructs like C++'s "class". Something else the languages do is facilitate "data-hiding", by allowing you to specify with language constructs (C++'s "public" "private" and "protected") which members are for general users of the class, and which members are for the class's internal use only. Nothing special here - you can do this in C also. C++ just gives you some language constructs to enforce it at compile-time, and perhaps make things a little more organized and readable.
2. Inheritance. OO languages typically allow these encapsulated objects to 'inherit' behaviour from other objects. This is quite powerful; with a single line of code specifying what to inherit from, your object gains a whole lot of new functionality "for free". Once again though, there is very little special here, it can all still be done with imperative languages. OO languages just, once again, make this concept more a part of the syntax and constructs of the language. Inheritance also allows you to override methods, so if the object you inherit from has a function, you can redefine that function to behave differently.
3. Polymorphism. Also called late binding. Probably the most powerful aspect of OOP (although, yes, once again, you can hack something in a language like C that will mimick the same behaviour.) Polymorphism is like inheritance, except the version of an overridden function that gets called is determined at runtime rather than compile time, and uses a table of pointers to methods called a "virtual method table". A little difficult to explain .. if I have a generic "widget" class with a function called "Draw", then specific types of widgets (e.g. scroll bars, buttons etc) would firstly inherit from the general widget, and then override the virtual method "Draw". Now a program that handled the user interface can just have alist of pointers to generic widgets (which will in reality be scroll bars, buttons etc), and it does not have to worry about what sort of widget they are, it just has to call the "Draw" function on each of them when it needs them to be drawn to the screen, and using the vmt, the correct "Draw" will be called depending on what type of widget it is.

   Sounds like you've done mostly encapsulation, maybe a bit of inheritance is natural too. Probably not polymorphism though.

   The thing about OOP is, although it supports these concepts in the language, it doesn't automatically lead to good design, and that is the point that the author of the article this whole thread is about seems to have missed. You still have to think about your design very carefully to build good reusable components. In general it does make you think a little bit more carefully before you just start coding away, which isn't a bad thing. There is nothing you can do in C++ though that you can't do in C. C++ just lends itself more readily to expressing certain types of ideas within the language's native syntax, e.g. picture the "gtk+" toolkit without all the ugly hacky typecast macros and the hacky inheritance structure.

   Presumably there are some OO zealots out there (I personally don't know any but the article author seems to think almost every C++ programmer is an OOP zealot) but in general I think most OOP programmers are more focused on solving real-world problems than on spreading hype. For every rabid OOP zealot, there's a rabid anti-OOP zealot. This guys just one of the rabid anti-OOP zealots. When you really do speak to most people in the business, they *dont* have big issues about programming paradigms. They just use the best tool for the job and are actually mature about it.

OOP *is* really the next level

I fought it for many years, and finally gave in. Now I wonder how I ever got by without it.

There are applications - small ones - for which OOP is not appropriate. Code which generates web pages, for example, is generately best written in a procedural language. The vast majority of applications, however, are easier to extend and maintain (although not necessarily write, at least until you've been doing it for quite a while) if written with OO.

And of course, you don't need an OO language to use OO. The Linux kernel is very OO, and it's written in C.

FWIW, the examples given in this article are terrible. Not only are they not very relevant, but they are badly written. If someone I was working with wrote OO code like that, I'd seriously question their ability as a programmer.

Re:The King of Argument By Authority (Addison)

I roundly disagree with the arguments presented against OOP, on the basis that the author's own references cite the advantages of it, as well as the disadvantages. The consensus on the reference *academic paper* is that it had advantages, but is not necessarily "revolutionary". Indeed, OOP codifies much of what *can* be done with good programming practice in procedural or even functional programming.

My experience in systems design is that OOP shows benefit when you know it, and with larger *REAL* systems. Networked apps, distributed apps, and yes, even large business apps. I've been involved in an IS project written completely in C, using good, structured programming techniques. At a different company, we were building a similar application, using C but applying a more data-centric approach, close to OOP but not there yet. It was much quicker to build, and easier to enhance. If I took a crack at the domain yet again with OOP and C++/Java, I know it could be improved yet again.

The issue though, is that if it's one guy, building a one-shot fire and forget app, don't bother. Code it however you want. If you have a significant project with multiple team members, OOP acts as a common framework and a basis for communication. It draws some borders and sets some guidelines and methods to give a common frame of reference. It's possible, but more difficult to do that with procedural code in *most* cases.

Obviously though, the proof, as the author says, is in the pudding. Millions upon millions of development dollars is OBVIOUSLY being wasted by the industry as it moves to use OOP methodologies and tools. Not just as dictated by PHBs, but also as dictated in start-ups by lead programmers.

Quote from a pundit who knows the industry better than most of us, Robert Cringely, from a slashdot interview no less:

Something else that has changed a lot is how software is written. OOP has paid off more than we even know, so there are a lot of chances to make businesses out of selling cogs that fit into other people's machines. Your driver question, for example, wouldn't have even made sense a decade ago.

Hmm. More than one company now. There's a benefit. Predefined interfaces and component technologies. Can you do that in procedural approaches, yes. Is it easier and more natural and efficient in OOP, yes.

And finally, as I don't want to get too long, let's take another /. post, a reply from John Carmack.

First of all, the fact that none of our deployed games used OOP does not mean that I don't think there are benefits to it. In the early days, there were portability, performance, and bloat problems with it, so we never chose to deploy with it. However, all of the tools for DOOM and Quake were developed in Obejctive-C on NEXTSTEP. Q3 also came fairly close to have a JVM instead of the QVM interpreter, but it didn't quite fit my needs. I'm still not a huge C++ fan, but anyone that will flat out deny the benefits of OOP for some specific classes of problems like UI programming and some game logic is bordering on being a luddite. I still don't think it is beneficial everywhere, but, if anything, I think we are behind the curve on making the transition.

Hmm. Use the best fitting tool. But even a die-hard success phenomenon like John Carmack seems to think OOP is good for things link UI AND game logic. Not everywhere. No argument from me.

Jeez, I think he essentially can be construed as having called the author of the original post a luddite.

I tend to agree.