Skip to main content

The way I use Design Patterns in my code is

select appropriate ones during design phase.
26% (99 votes)
to clean up code when a pattern would help.
21% (80 votes)
subconsciously because they are part of me.
41% (156 votes)
when told to.
2% (8 votes)
Other (add comment)
1% (2 votes)
Not at all.
9% (34 votes)
Total votes: 379


when ever

I use them when ever appropriate, during all phases of development, consciously and subconsciously, from analysis code, understanding code quality, testing, design, development, etc.


The trick to patterns, in general, is to define your software requirements first, and identify potential issues. Once you have done that, you can investigate design patterns which can help you solve the issue. Going into design saying, i want to use this pattern, and i want to use that pattern is a bad way to design software, and leads to unintelligible designs (ie, reference Command pattern when used for non-extensible systems). Good use leads to simpler, extensible code (reference DAO pattern) Bottom line, don't use patterns just to say you used them.

Interesting for the uninitiated

huh? I think everyone who understands patterns understands what I mean. Because of the continuing hype about 'patterns' people think there must be something in it. It takes some time to open the box but when the box is open all you is void, empty space. You suddenly realize that you were trying to learn something you mastered ages ago. This trick is one of the oldest in history, I suppose.

Gang of Four Patterns Book

Every now and again I like to reread the G0F patterns book so as to brush up on my 'BS-detector-fu' for my regular clashes with architects. Every time I'm struck by just how many of them are mostly irrelevant in Java. I'm like: 'gee, thats fascinating, I could do that... or... alternately... *I could just use an Interface*'. Patterns are a good thing for C++ and Smalltalk I'm sure, but they seem to be mostly about different ways of abstracting an interface away from the implementation. But of course, Java already has a 100% abstract interface mechanism deeply embedded in the language. Its a bit like talking to a functional programmer (eg a Lisp-er) about iterators... they'll just give you this kind of blank look and go... "yeah... well... that's nice and all, but I think I'll keep using closures, thanks for sharing!".