Rethinking Design Patterns

blog
21

Hey, Jeff-

I’ve been reading your blog for a while now and I love how all of your articles link to each other to present a complete picture of your point of view.

I think, however, it may be helpful to add (with a question mark; underscores for spaces) the linked article’s title after the URL; as in the following:

http://www.codinghorror.com/blog/archives/000380.html?Head_First_Design_Patterns

This may help with some clarity (“Ah, yes! I remember that one!”) that arises when you link random phrases to your previous articles.

Regards,
Petskull

22

“If you just blindly follow formulas, you are a chimp developer, and we all know there are too many out there.”

Actually I want to blindly follow formulas. Software development is so complex and I’m so stupid that if there are techniques that I can apply without thinking then I can use the thinking that I save there on other things that I really need to think deeply about.

This applies to more than design patterns but to algorithms and logic. Why kill your brain trying to reinvent sorting algorithms when someone has already solved your problem before? Why struggle with developing your own coding standards when you can use one of the many standards out there? Why create your own image processing library when you can reuse somebody else’s?

Programming is hard. If there’s something out there that helps me to cheat and get things done faster and better than would have happened if I reinvented the wheel, then damnit I want to use it. If that makes me mindless or makes people think that I’m stupid then I’m happy with that.

23

I definitely agree that developers need absorb ideas (i. e., read books) from other disciplines. But, at 1,216 pages, that’s a waste of time, unless you plan to switch careers.

24

Design patterns sure are a classic. We should write a song about them…

Yeah, they say two thousand patterns patterns party over
Oops out of time
So tonight I’m gonna program like it’s 1999
Yeah

As programmers we need to remember that design patterns are solutions to problems, and not implementations to problems.

25

The issue is less with the GoF’s “Design Patterns” and more with the actual people reading it. Some people read it looking for a quick fix, hence creating a copy-and-paste template generating programmer while others read it, digest it, think about it and come out with some good bits.

Personally when I read it so long ago what it really did was give me different ways to view how objects interact, different ways to couple and decouple frameworks, different contexts for more abstract classes, etc. Since most of the examples are in SmallTalk if I remember rightly there really was no chance for me to copy and paste, I had to think about application and approach and while I’ve never used many patterns I always thought about how to structure things so they were simple and well-organized.

Everyone learns differently and some people you have to “force” to actually think because otherwise they’ll just mimic. There are others that can learn from looking at well written source code, turning the implemented ideas into lessons. Personally I’m in the latter category which is why I got a lot out of “Design Patterns” and when I did read “A Pattern Language” afterwards I felt it dragged on, labouring over concepts that I had already inferred from “Design Patterns”. Then again I never had “Design Patterns” next to my computer, trying to use it like some code template handbook, instead I’d read it before bed, on road trips or just on my deck with a nice cigar.

I don’t think either is better, just different, which is why it’s important that there’s many different views and approaches to teaching the same basic thing.

26

I don’t know if it’s that the Gang of Four didn’t “get” Christopher Alexander, or if it’s that almost nobody “gets” the Gang of Four. I actually think the second scenario is more likely, especially as the book is so dense that it’s nearly unreadable. For example, the patterns are in alphabetical order instead of increasing order of usefulness, etc. Other authors have done a much better job of making the (good) core concepts more accessible.

The design patterns gurus I’ve worked with have always said that the pattern is in the encapsulation of the forces in a problem, and aren’t boilerplate solutions. The diagrams in the book aren’t
the patterns", they are just one example of a way to implement the patterns. If your implementation is different, that’s great.

If a pattern-oriented design is more complex, you’re probably misusing the pattern. You have to use a more sophisticated measure of complexity than just “number of classes”, though.

It’s a shame that the whole design patterns mindset is so easily misunderstood and incorrectly applied. I’ve found knowledge of patterns has really improved the quality of my code and my ability to communicate design to other developers.

27

I definitely agree that developers need absorb ideas (i. e., read books) from other disciplines. But, at 1,216 pages, that’s a waste of time, unless you plan to switch careers.

Use the Amazon “search inside” function to browse A Pattern Language. I don’t think it’s the type of book you read cover-to-cover.

But you got my intent: absorb the deeper ideas and think for yourself about how these might (or might not) apply to software development.

28

I’m not sure what’s worse: A junior developer who slavishly adheres to design patterns or, as was my recent experience, a junior developer who shares the sentiments of your blog post and has concluded that design patterns are for ninnies, so why bother with them?

To me, design patterns represent frequently elegant solutions to common problems. I’d much prefer a junior developer working under me to slavishly grasp and adhere to a design pattern than to strike out on his own and decide he’s got a “better” solution to a common problem than the four numbskulls who wrote the book!

29

not mentioned yet, so Holub’s book on design patterns is an antidote for mindless doting. and he’s an iconoclast of The First Water.

30

I have read A Pattern Language and I have to agree with Mark Dominus’s sentiments that Design Patterns just doesn’t match up to A Pattern Language. Where A Pattern Language has 250 short patterns, Design Patterns has about 20 huge ones. Design Patterns tends to treat them only at one level, and in too much detail. A Pattern Language looks at patterns over a much larger scale and in more general terms.

I think a cs book that did follow in the same vain as A Pattern Language would cover things from a high level, such as patterns for deployment, down to parsers, and different patterns used there. But in all would remain fairly general. It’s probably too much for a single book to cover though.

As far the Design Patterns book goes as a Object Oriented learning mechanism it does a reasonable job at that. Though I think if a developer is at the stage where they could read and grok Design Patterns, they should read “Refactoring” by Martin Fowler first. I’d almost say that it’s more true to the spirit of the original patterns book than Design Patterns is.

31

I don’t see the problem.

If I have something I need to do, I simply file a bug report with the compiler vendor demanding they add the relevant feature to the language, then in less than a year I purchase the upgrade with the feature that solves my problem without me needing to do anything.

What’s wrong with that? All software development problems without exception are flaws in languages, after all. Hell, it only took half an hour to redesign perl with all required features that have been discovered in computing, so how long can it take to add a new feature to an existing language. Clearly having a way to solve a known problem using existing compilers and language features is pathetically stupid when you can just upgrade your language with new features.

Well, ok, the language reference now requires three large shipping containers because there’s a whole lot of problems that have needed solved and the number of language features has gotten a little larger than it started out, but the electronic version can be searched easily enough.

32

If you rethink design patterns, maybe you are ready for refactoring

“Refactoring: Improving the Design of Existing Code”

a href="http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672"http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/a

Cheers!

33

"If I have something I need to do, I simply file a bug report with the compiler vendor demanding they add the relevant feature to the language, then in less than a year I purchase the upgrade with the feature that solves my problem without me needing to do anything.

What’s wrong with that?"

Your manager is willing to wait a year for a project?

34

"If I have something I need to do, I simply file a bug report with the compiler vendor demanding they add the relevant feature to the language, then in less than a year I purchase the upgrade with the feature that solves my problem without me needing to do anything.

What’s wrong with that?"

I HOPE you’re joking.

35

Further reading on Christopher Alexander: Richard Gabriel’s “Patterns of Software”:
http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

More recently, Steve Yegge had something to say about QWAN:
http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html

36

I agree to a certain extend; the Design Patterns book basically contains the recipes for several recurring problems in software development. The key is to go a little bit higher in abstraction level and think about the idea of recognizing a recurring pattern while you are developing software. And that is a powerful concept. But, yes, not everyone will interpret the book like that.

On my own blog, I wrote an article about the vocabulary of software design, which more or less reflects the level of abstraction to recognize design and patterns in software architectures:

http://www.code-muse.com/blog/?p=4

Alexander’s book is now surely high on my wishlist of books to read!

37

For this one time I have to slightly disagree with you Jeff, and while overusage of Design Patterns is a clear sign of a clueless architect that should probably find a different line of work I think Design Patterns are an essential tool. If you use them often you are doing something wrong? I don’t like that flat out blanket statement, it just doesn’t hold up, I mean perhaps to a UI developer thats true, but a back end developer or an architect it’s definitely not the case. Time and time again I have used patterns but I think most people miss the point of patterns, you don’t have to follow a pattern to its concise design. I see them more as a blue print that you mold to your needs, change this, change that, until it works for you, don’t fit a square peg into a round hole just for the sake of using the pattern.

More often than not most developers who shy away from patterns in my experience have done so because they failed to adapt them to their needs or they simply used the wrong pattern for the wrong thing. I have actually seen a UI developer use the factory pattern for a UI control?!

Patterns are a necessity to information reuse, if you build a bridge you don’t start from scratch do you? Every single bridge in the world uses reinforced concrete, I mean I hate analogies like this in software where you compare software architecture to real world architecture but it gets the point across…

I do agree that its good to understand your lines, don’t use patterns for the sake of using them, for god sake this happens so often its quit annoying. I have been on projects where the lead developer would hand everyone a design pattern book and say read this, this is how we are going to design our application. Which left all the junior developers with a “Huh?” look on their face all confused… They are there to aid you in a specific common problem…

I do agree with you about th cut-paste mentality with design patterns, DONT DO IT, but should developers shy away from patterns? WHY? It’s a tool in their arsenal and they should use it when necessary!

38

People keep bashing on GoF for conflicting reasons: it’s too simple, requiring no thought; it’s too complicated, the patterns are huge; it’s too low level, bogged by implementations instead of abstractions; it’s too abstract, not considering real world implementation issues; and so on…

The truth is that even the best books are not for everyone. Some will call Fred Brooks’ book largely irrelevant. “Code Complete” is huge and contains a lot of advice that is just a matter of style and not quality. “Effective C++” is too simple, and only shows toy examples and not real world examples. The list goes on.
Yet most of us agree that these books are very important, and many would agree that they are among the best available. GoF (and other books) are very easy targets. So is C++ (in a different way, perhaps).
People like bashing them, but the truth is that they enabled breakthroughs in real world software development, and are still very useful tools on the road to quality.

On another, related note:
Steve Yegge also doesn’t like design patterns, and believes like others here that they point to deficiency in the language.

“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++.”

http://steve.yegge.googlepages.com/singleton-considered-stupid

That’s fine. Maybe we should all use LISP, or at least Haskell. C++ really sucks, or whatever. Man, overload resolution is a real hack.

In the meanwhile, I have real work to do.
I really need to get that image display UI for that digital camera working. I don’t know of any LISP implementation that runs well enough on a digital camera. LISP is simply not an option (yet?). So I am gonna do it in C++. I might use a design pattern here or there, even (GASP!) a Visitor. Because I recognize that patterns are simply that: recurring OO design solutions to recurring problems.

When you are holding that digital camera and browsing through your hundreds of photos in lightning speed, organizing them, and resorting them, you will be glad I used C++, and employed all tools and methods available to me. You won’t know it, of course. Your software will simply work. It will work very well: fast, easy, no crashes. But it will do so because I considered the design carefully, coded with discipline, and tested as best as I could. The design patterns book is just another tool.

39

I think your argument has a rather painful fallacy in it…The problem isn’t Design Patterns, the problem is the quality of the engineer/architect that tries to use them. If I apply your logic in the construction arena, then we must surely blame the failure of buildings and structures on the slavish use of AutoCAD and poorly designed hammers. In other words, the tools are rarely the issue–be they patterns or languages.

It still comes down to the fact that good engineers and architects know how to use their tools well and that poor ones, even when given the best ‘chisels and screwdrivers’, can’t program their way out of a wet paper bag. Plain and simple. 15 years in the trenches has yet to teach me differently.

40

The problem isn’t even design patterns related.

I think the problem is newbie programmers or those that seem to still have the behavior of wanting to blindly implement this cool-new-thing ™ they learned… and implement it all over the place.

Lacking sight of the big picture and the true point is also lacking for these people.

We’ve all been guilty of facination of the cool-new-thing, yet over time we learn better what to do with this information. Especially after you’ve been maintaining a codebase for years, you pick up a few things :wink:

Maybe it’s part of the learning process? I don’t know. At least comment the code that you’re patterning all over the place :smiley:

ps - I also am a fan of Martin Fowler’s Refactoring book and the Head First Design Patterns book (in fact I’m a fan of all of Kathy Sierra’s books/Head First).