Today we’re looking over a book that is oft-cited as a fan favorite for object-oriented design: Design Patterns. Many computer science students see it during their software engineering course, although my first exposure to it was relatively recently. But while many others love this book, it just didn’t hit me the same way.
Looking at other posts in the blogosphere, the opinion of Design Patterns is all over the map. So for those of you who haven’t read the book, I’ll give you the “sales pitch” on this book in a short little blurb:
Object-oriented developers need ways to help them design truly object-oriented software using time-tested practices. This book gives you just that!
So the book definitely does this. No doubt about it. Yet I debate the legendary status behind the book. It’s great for a computer science class on software engineering, and I wish I had seen it when I was an undergraduate. These patterns are general purpose solutions to what are apparently the big problems plaguing OO programmers.
The keyword here is apparently. Of course the “Gang of Four,” the name dubbed to these four authors, couldn’t cover everything ever. And it’s hard for me to judge them, since if you compare me to them, I am obviously a n00b.
So I have to do with this what I did with POSA 2: Make photocopies of the first two pages, which summarize what the patterns do, and when a problem comes up that sounds similar to this, read up on it. The examples they give are fine, but I really get more out of it when I’ve seen a problem similar to it (e.g., my whole rant on the Wrapper Facade was inspired by a problem in one of my grad classes that this would have solved very nicely).
For me, the best part of this book is…the introduction. The Gang of Four essentially sell you on their point of view in this chapter, and they do a great job on it. They try to convince you that interfaces are good, and inheritance is bad as far as being pure OO. The gist of the argument is that OO is, at its core, the following: polymorphism, encapsulation, and abstraction. When you use inheritance, it’s because there’s some code you want to reuse from something similar, thereby breaking the encapsulation. If the person you’re inheriting code from changes their code, you potentially are screwed.
That’s not to say inheritance and code reuse are bad. They’re wonderful. They just, at an ideological level, break what we were taught OO was in college. And that’s fine too. So to have their cake (OO) and eat it too (get code reuse), we have Design Patterns.
It reads like an encyclopedia, but just like the other pattern books, if you have a problem that resembles one of these, you are in luck. These guys have had these problems for years and have excellent solutions to them. And reading up on these problems may put you in a good spot for later. But it seems like the opposite happens: everyone ends up seeing everything as the Singleton pattern (just make your objects static and global), and the point of Design Patterns (and OO) is lost altogether.