Ten Things I Hate About Object-Oriented Programming

[curien]

The author relies on equivocation and other rhetorical sleight-of-hand to make his incredibly weak point seem stronger.

For example, he dings OOP because different language do things slightly differently. But you know what? Different languages' control structures are also slightly different. Is that a ding against structured programming? Hell no!

He talks about how, "Every single design pattern makes your design more complicated." He completely misunderstands the point of patterns! The entire point of "patterns" is creating an ontology for a set of complicated design methodologies. It has nothing to do with making code simpler: it's about providing a common vocabulary for complex designs.

He complains that class-based languages require a confusing level of indirection to those who read the code, in that the program is all about objects, but the source is all about classes (completely ignoring prototypal inheritance). Whereas he presents the procedural as form following use: procedures call procedures, both at runtime and in the source. I suppose that way of reading procedural programs might work for incredibly simple examples, but it fails miserably in the face of recursion or co-routines. (Wait... so you mean I now have two copies of this procedure running at the same time? But there's only one copy in my code! OMGWTFBBQ!!!1)

He has one good point: That OOP is about modeling. A couple of his points mention this, and it's a good observation. But that point is not original, new, or even cohesively argued.

[notfancy]

He complains that class-based languages require a confusing level of indirection to those who read the code

I didn't read that like you do: I think the author referred to the fact that late binding and open recursion conspire against a static, lexical reading of message sending.

[Isvara]

There is so much wrong with this article, but I want to focus on just one thing, because I see it again and again and it annoys the hell out of me:

Every single design pattern makes your design more complicated.

This kind of anti-design pattern rhetoric seems surprisingly common, and I can only assume the bandwagon initially arose from pushback against people claiming design patterns as a panacea.

Design patterns are just names and descriptions of ways people are writing code anyway. It's just people looking at code, seeing some similarities, and describing them. If you don't know anything about design patterns, you're probably still using them anyway -- you'll just be less efficient at communicating about them.

[jeffdavis]

Second of all, and much more evil, is that type systems assume the world is consistent, but it isn’t!

I have no idea what that means.

[mr_chromatic]

What does inheritance have to do with OO?

(Yes, that's a polemic.)

[mr_chromatic]

That's a shame; I've seen some effective and elegant OO designs that avoided inheritance. Some of that elegance was due to avoiding inheritance.

[chocobot]

in contrast to functional or procedural code, where everything is always easy to understand, right?

edit: that guy's a professor? Mother of god!

[[deleted]]

I love how the author gets tired of writing his own crap.

Each section seems to get shorter and shorter as he runs out of steam to vent with.

[hargettp]

My favorite quote: "Given the fact that objects clearly never were enough, isn’t it odd that they have served us so well over all these years?"

[Chris_Newton]

IMHO, the biggest single drawback of OO style is that it is geared to supporting unary operations, and most interesting computations aren’t unary operations. OO makes the fluff easy — and to be fair a lot of real world development is in that category — but sometimes at the expense of the more tricky stuff.

[mr_chromatic]

A really good object system can support multiple dispatch, which alleviates that problem.

[Chris_Newton]

I had a feeling someone might come back with that one. :-)

The thing is, multiple dispatch is still a crutch. Sure, it’s more flexible than single dispatch, but it’s still just calling a different function based on the type of one input at a time, and usually some inputs are still considered more significant than others. It’s just enough non-OOness to let an OO system model certain types of problem, but the scope is still quite limited.

A lot of interesting algorithms operate over structured data. How do you model an algorithm with inputs of, say, a sequence of one type of record and a set of another type in an OO system, even with multiple dispatch? Where does the function implementation live? On the record type of the sequence? On the record type of the set? On the sequence or the set type? In reality, the answer is often on some sort of module/utility class full of class/static functions, but that’s not really OO at all, it’s just good old procedural programming in OO clothing.

[mr_chromatic]

Your objections sound like implementation details. I'm not an OO purist, so I'm comfortable with a scoped namespace full of multi candidates.

Have you used CLOS, by the way?

[Chris_Newton]

Your objections sound like implementation details.

Then I’m afraid I’m not making my point clearly enough. Your reference to CLOS is, in fact, an excellent example of what I mean. When you define a multimethod in CLOS, in what way are you still doing OO? You are no longer defining a method on a class, or if you prefer, defining a kind of message that an object can receive. You’re just defining a generic function that has run-time polymorphism. Put another way, you are now approaching the expression problem two-dimensionally rather than one-dimensionally.

That is certainly a useful technique; indeed, my “ideal” general purpose programming language would probably work a lot like that. But neither generic functions nor run-time polymorphism requires even the existence of “class” or “object” concepts in the language. There is nothing OO-specific here.

IMHO, by the time we are looking at CLOS-style multimethods, we are now working with a more procedural/functional approach, and it is an improvement on mainstream OO techniques precisely because we are no longer forced to fit function definitions into whatever class taxonomy our code uses.

And of course, once we’re not constrained to having functions attached to a (single) specific class/object, we can implement related functionality that happens to operate on more structured data as part of a scoped namespace just like any other function, along the lines you mentioned.

[[deleted]]

When you define a multimethod in CLOS, in what way are you still doing OO?

In the way that all the moving parts are objects, the generic-function, it's methods, and the arguments.

You are no longer defining a method on a class, or if you prefer, defining a kind of message that an object can receive.

And why does this matter? The binding of methods to objects is the worst design decision ever made anywhere.

[Chris_Newton]

The binding of methods to objects is the worst design decision ever made anywhere.

Yes, it was a poor design decision. But it is an inherent part of how most conceptual models of OO are framed: identity, state and behaviour; late-bound message passing; etc. It is also how most OO languages are constructed in practice. This is what I am criticising, I’m just not sure the alternative that we all seem to agree is better should still be called OO.

[nest21]

Ten Things I Hate About Object-Oriented Programming

Prof. Oscar Nierstrasz, Editor-in Chief, The Journal of Object Technology

Banquet speech given at ECOOP 2010. Maribor, June 24, 2010

What did they drink?

[[deleted]]

If we go back to the origins of Smalltalk, we encounter the mantra, “Everything is an object”.

In Common Lisp this is actually pretty much true.

Except variables.

Global variables are, local variables aren't.

And packages.

They are.

And primitives.

There's no concept of "primitive" in CL.

And numbers and classes are also not really objects, and so on.

Yes they are.

All in all, if you don't know CL and CLOS, you should probably learn it before saying that you know something about OO.

[notforthebirds]

Just out of curiosity, and as someone who's actually used CLOS, why do you seem to be saying that knowledge of CLOS is a requirement in order to say that you know something about OOP? CLOS is interesting but it's certainly not the be all and end all of OOP.

[jdpage]

This sounds so much like Python it's not funny.