Good stuff, but the "OOP is Bad" site doesn't belong to the author, it belongs to a megalomaniac nut named Bryce Jacobs. Just search for "Topmind" in Google groups to see what I mean.

Enjoyed your post. I too read Richard's article last week and thought it was interesting. I myself prefer to KISS whenever possible and not build a submarine when a rowboat will do.

You may enjoy this one as well:
http://www.devx.com/opinion/Article/22649

Leigh

I'm not that impressed with the author's credentials. Looks to me like he's spent most of his time writing about programming - not doing it.

Most professional programmers know that OOP is just one tool in the toolbox. The skilled ones know when to use it - and when to use something else.

> Most professional programmers know that OOP is just one tool in the toolbox. The skilled ones know when to use it - and when to use something else

I agree. But the question is, which of these systems (OOP or procedural) produces better results in the hands of a naive, inexperienced developer? Because that's invariably what you're going to get.

Well designed methodologies/systems are designed to accommodate human error and inexperience. I'm not convinced the fancy patterns do this particularly well. They seem to require a high level of skill to A) determine when to use and B) implement correctly without overly complicating the code.

Havin' fun with it...
http://theserverside.com/news/thread.tss?thread_id=31439

Thanks for pointing that out. Some reasonable responses to an overly religious article. This response in particular stood out to me:

--

> But one thing I have to admit: badly written OO code is IMHO worse than badly written procedural code. With "bad" I mean OO programs that are bloated because of excessive usage of patterns and ignoring the principle of simplicity. I'm actually trying to fix such a beast and it's so hard because the whole thing is absurdly complex with unnecessary abstractions, factories, proxies, managers, visitors and so on, just the whole catalogue of the GOF-Book. Bad procedural code often comes around in the form of long files of spaghetti code which can be quite easily wrapped up in a class and be locked away forever.

That is a great quote Jeff. There was a comment up there too about how too many abstractions are like chasing down way too many goto statements. That one had me bustin' up.

Stuart Halloway takes the interesting view in his "Design Patterns Revisited" presentation that, in some sense, design patterns are missing elements of the language. He provides techniques using things like reflection and aspects to add them in. Some languages (Objective-C) allow you to add elements in as base components of the language, which reduces the complexity of the patterns to the point that they just become the tools that they are intended to be.

Hey Jeff, totally agreed patterns are great shared vocabularies, not implementations. But, with the Head First decorator comment, think about it from the perspective of someone learning the patterns (not an OO expert like yourself). Would the coffee pricing example stick in your head so that when you're actually working on a REAL implementation you'd have the essence of the pattern in your head? That's the whole point with Head First - learning, and in a way that makes people feel like they can go out and use the patterns, not in a way that makes them feel like a dummy. If you read the amazon reviews you'll see people really do benefit from this approach.

Anyway, hope you're enjoying the book.

Best,

Eric

Head First Design Patterns was written specifically NOT to be Design Patterns for Dummies. Our readers are not dummies, they are beginners, who haven't yet had the opportunity to learn about design patterns.

> Stuart Halloway takes the interesting view in his "Design Patterns Revisited" presentation that, in some sense, design patterns are missing elements of the language

Agreed. I remember Paul Graham commenting that over half the patterns exist as language elements in Lisp. The best patterns are probably invisible because they're part of the language.

> Would the coffee pricing example stick in your head so that when you're actually working on a REAL implementation you'd have the essence of the pattern in your head? That's the whole point with Head First - learning, and in a way that makes people feel like they can go out and use the patterns

My concern is that beginners aren't learning when a pattern is appropriate in a real world situation. This leads to inappropriate use of patterns in simple situations-- exactly as shown in the Head First example-- which leads to overly complex code (see quote above). That's a classic beginner mistake. Simple situations deserve simple solutions.

> Head First Design Patterns was written specifically NOT to be Design Patterns for Dummies

I didn't mean it in a pejorative sense.. I prefer books like Head First. I don't enjoy dry academic books, and I'm sure four out of five Amazon readers would agree!

Jeff, I think that's a valid concern and as always there is a tradeoff between understanding the pattern versus getting lost in a complex, say, payroll or graphics application just to see where it might fit. We do fit decorator into the context of Java I/O after explaining the simple pattern. We also address the "novice user seeing patterns everywhere" issue in the last chapter (as well as elsewhere).

Keep the comments coming! It can only improve future editions.

Eric

There is very little coded evidence or demonstration pieces. Instead, it is a battle of anecdotes. We should expect more. This is the age of science, no? Also, most evidence examples seem to be from systems software. Is it perhaps the case that OOP does not work too well for business software? Interfaces are perhaps more stable in systems software due to de-facto standards. In that case, swappability of implementation, and thus polymorphism, makes more sense there. Maybe it is just that OOP's shine is not domain-universal. This is why the best OOP examples are for systems software.

Any textbook explanation of a complex technique will almost inevitably use bad examples. For a textbook, we want to use a simple example because the point is to demonstrate the technique and not get bogged down in the specific application. If I'm trying to explain, say, how inheritence works in OOP, I'd probably do it with some trivial operation like the parent adding two numbers together and the child over-riding this with a function that multiplies. I wouldn't use a completely-developed model of mitosis in mitochondrial DNA, subtyped to handle meiosis, because the reader would then have to spend hours understanding the biology rather than learning the programming.

Thus, many textbook examples use a complex technique where no programmer in his right mind would use such a complex technique. If I really wanted to find out what 2+3 is, I wouldn't write an object-oriented program with a hierarchy six deep, a web page, and a back-end database. Even "System.out.println(2+3);" would be far more complexity than called for. I would not use a computer at all. I would simply count on my fingers.

Surely no one would suggest that all textbooks examples should be sufficiently complex to merit the use of the technique being explained.

But there is the danger that if this point is not carefully explained to the student, he might get the very wrong idea that complex techniques should or must be used in such simple problems.

I've seen plenty of examples of code that is far more complex than necessary or appropriate to the problem. I've often wondered if the programmer used this technique because he really felt it was useful here or just because he remembered seeing it somewhere else and blindly applied it to the existing problem. Maybe this is how some of that happens.