April 22nd, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
Design Patterns was especially well-timed because it offered a ray of hope for people who were mired in the Woes of the New OO Programmer. You see, the OO camp was saying: “EVERYTHING IS AN OBJECT! YOU WILL THINK OF EVERYTHING AS OBJECTS FROM NOW ON! THE OO PROGRAMMING PARADIGM IS: CREATE YOUR CLASSES, ADD OPERATIONS TO THEM, AND LAUNCH THE DAMN THING!”
The last sentence (forgive the caps, sorry) is a pretty reasonable paraphrase of Stroustroup in his “The C++ Programming Language” book, where in Chapter Two he says that the programming paradigm is “Decide which types you want; provide a full set of operations for each type.”
Everyone believed him, and they went and defined their types, which just stared back balefully.
Bob: “Hey Fred, how do I model a Loop?”
Fred: “Easy! Make a Loop class.”
Bob: “OK. What operations should it have?”
Fred: “Um, lemme look. Prolly give it a parent, and instantiate it with a number of iterations and a stopping point.”
Bob: “Wow, this OOP solves everything! What code should I put in the doLoop() method?”
Fred: “I think that’s where you instantiate it”
Bob: “That’s so cool, it’s almost… confusing.”
Fred: “Make sure you make it a Singleton. I’ve never seen a reason not to.”
Everyone was bought into the fact that OOP was the future, and also the past, since Marketing felt it was important to make everyone forget what existed before OOP, in case they might start to have doubts. But there were a few open questions, such as how to model relationships between types, a problem Stroustroup had most conveniently overlooked in his Magnum Opus.
Stroustroup: As you can see, operator overloading has proven extremely useful, which I will demonstrate for the 16th time by once again using the Complex Number class. See how useful it is to have the + operator for this class? I sure love this example. Don’t you?
Readers: Wow. He’s right. It is useful.
Stroustroup did a wonderful job of marketing C++, and because you could learn it one feature at a time (“I like the double-slash comments”), it was an attractive proposition for all the bad C programmers out there.
But Stroustroup was utterly silent on the issue of how classes actually interact, and the first book to come along and package up an idea with equally good marketing was Design Patterns. It showed people some convenient and (mostly) intuitive ways for small groups of objects to collaborate to solve situations you run into all the time. Cool stuff!
The problem is, about 1/3 to 1/2 of them were basically cover-ups for deficiencies in C++ that don’t exist in other languages. Although I’m not a huge Perl fan anymore, I have to admit the Perl community caught on to this first (or at least funniest). They pointed out that many of these so-called patterns were actually an implementation of Functional Programming in C++.
The Visitor, for instance, is just a class wrapper for a function with some accumulator variables, something that’s achieved far more cleanly with, say, the map() function in higher-level languages. Iterator is a poor man’s Visitor. The Strategy pattern is beautiful on the surface, but Strategy objects are typically stateless, which means they’re really just first-order functions in disguise. (If they have state, then they’re Closures in disguise.) Etc. You either get this, because you’ve done functional programming before, or you don’t, in which case I sound like I’m a babbling idiot, so I guess I’ll wrap it up.