
Design patterns have (mostly) flopped  - andrewstuart
http://www.supercoders.com.au/blog/designpatternshavemostlyflopped.shtml
======
mjw
How about this:

Design patterns have flopped because many if not most of them have proven not
to be the universal computer science gems they were touted as.

Rather, they've proven to be:

* Stock workarounds for the overly restrictive type system of a particular language X

* Patterns which in a more powerful language would be a language feature (or trivially abstracted into a small chunk of library code using the language's existing facilities for abstraction) -- but in language X, require so much boilerplate for each invocation, that the boilerplate merits a special name.

(Where for X, substitute mostly Java :)

~~~
brazzy
Even in Java, most patterns can be implemented just fine in a small chunk of
library code using the language's existing facilities for abstraction.

I think the relative popularity of design patterns in the Java community has
less to do with the verbosity of the language than with historical accident
(design patterns became popular at around the same time as Java).

------
klync
I wasn't sure whether to upvote this article, until I got to this line:

> Design patterns are a universal language that few people speak, a sort of
> Esperanto for programmers.

Exactly. And I fully expect many of the hackers here to chime in with 'oh,
that article is so wrong'. But, the thing is, HN geeks, _you_ are that rare
breed that knows and applies the patterns. I've met you, and I've worked with
you. And for every one of you I've met in my career, I've met 200 who couldn't
give a damn what a DTD is, let alone a pattern.

Design patterns are actually an excellent concept, but they won't really help
programming for the masses. And, the more we depend on computing in our lives,
the more we need programming as a technical discipline to be able to
accomodate the masses. For every structural engineer out there in the real
world there are probably a thousand architects. And for every architect, ten
thousand carpenters. I know an expert carpenter and I'm pretty sure he
couldn't calculate the tensile strength of a basswood 2x4, but he can sure
build me a deck!

~~~
ardit33
Counterpoints to what you are saying:

Actually the okay but not so good programmers are more likely to be hung up on
design patterns. They have learned few of them, and try to apply wherever they
can, even when they really shouldn't. Aslo people that tend to do over-
engineer a lot tend to overuse design patterns. Also you will see them in
interviewees asking a lot more about design patterns themselves than actually
coding/problem solving ability. It is is just a higher end version of asking
"programming trivia".

To the risk of being downvoted, I repeat again: overuse of design patterns is
a hallmark of mediocre programmers, or programmer that are not very
experienced yet (they may become really good one day, but not there yet).

~~~
vlado
Agree. Actually design patterns are really good to apply at refactoring time.
You often cannot foresee what problems you will be facing and how your code
will evolve in order to start trying to stuff in all the patterns you are
familiar with. Write code -> see a problem -> identify a possible pattern ->
refactor accordingly. This is also learning design patterns by doing.

~~~
hga
I've found that Anti-Patterns (<http://en.wikipedia.org/wiki/Anti-pattern>)
are the best approach for refactoring. They explicitly start with recognizing
a bad pattern (frequently one which once made sense but no longer does) and
then explicitly prescribe methods to refactor them into something better.

------
mansr
In my experience, few real-world problems fit neatly into one out of a handful
predefined patterns. Having a few typical models to draw inspiration from when
solving a problem is of course useful. Mindlessly applying a recipe without
consideration of the unique aspects of an individual problem instance will
inevitably lead to suboptimal or overly convoluted designs.

A skilled software engineer will recognise important aspects in a given
situation and design a suitable solution based on similar situations (patters)
without necessarily having a name for it.

Every attempt to formalise good engineering practices has met with a similar
fate. Be it structured programming, design patters, agile development, or
something else, they all fail when the chosen process is followed to the
letter at any cost, no matter how absurd the consequences.

------
GFischer
Something that bugs me about these articles is how the data is gathered:

"In the recruiting work I have done I've asked thousands of programmers to
explain the concept behind design patterns"

I'd have to find some data to back up what I suspect, which is that the bottom
X% of programmers (or at least would-be programmers) cycle through all those
job interviews where this lack of knowledge becomes apparent (unless you're
recruiting for a really high-level position where the top programmers might be
interested in applying, and even then many are already content where they
are).

So, if you're any good, you're not as likely to be interviewed, and so the
population is flawed.

That doesn't mean that design patterns have or have not flopped. At least,
every one of my coworkers have been taught the patterns. Whether we apply them
or not might merit a study, one with a methodology that doesn't mislead the
observer and where a more valid conclusion might be reached (it could even be
the same conclusion, that is, that they have flopped).

~~~
andrewstuart
Are you suggesting that great programmers tend not to have to go through the
normal job seeking process, being interviewed etc, and therefore it tends to
be the less competent programmers who end up having to go through interviews,
and that these lower skilled programmers don't know design patterns?

~~~
philwelch
The great programmers certainly go through _fewer_ interviews, since they tend
to get hired quicker. And then they have a job, so they don't do interviews
anymore. It's the incompetent programmers who are more likely to show up
because they're more likely to (a) be unemployed and (b) go through more
interviews before finding a job.

~~~
darwinGod
Really?? That's some strong opinion, which I disagree with.

~~~
loumf
This old Joel Spolsky article gives an argument to why that is:

[http://www.joelonsoftware.com/articles/FindingGreatDeveloper...](http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html)

If you believe that good programmers are more likely to be offered a job than
bad ones, it pretty much flows from that that bad programmers will be
interviewing more. If that's so, then you are more likely to interview bad
programmers. Statistically, on average, etc. Not in every case.

~~~
andrewstuart
Perhaps true that some good and great programmers get snapped up by people who
know them and never need to look at a job board.

It's not true in general however that good and great programmers don't have to
go through the normal channels to find jobs. I encounter many extremely
talented programmers who weren't just snapped up by their network of
colleagues.

~~~
philwelch
Even assuming great programmers do look at job boards and go through normal
channels, they're more likely to get hired and stay employed, which still
makes the numbers game work out like I described.

------
orenmazor
design patterns are recurring patterns in code. you may not know how often
you're solving problems in the same way, but patterns recur, even if they're
not one of the classic big-white-algorithms-book ones.

just because you dont have a class called Factory in your code, doesn't mean
you're not using one.

and finally, if your programmer doesnt know what design patterns are, do
yourself a favor and tell them to learn at LEAST what they are. they'll find a
use for them, guaranteed.

~~~
nickik
should i read GoF or SICP? What is more importend?

Mmmhh I think im going to spend more time on SICP and PAIP then on the Gof
Book and more programmers should do that.

~~~
hga
Unless you intend to or need to program in languages with weak abstraction
facilities (i.e. C++ and Java) there's little need to read the GoF book. If
you know Lisp (i.e. have done SICP) then reading the GoF book will result in a
"Where's the beef?" reaction, at least if you're anything like me.

------
brazzy
Design patterns are not, and never will be "important field of computer
science".

They're a neat-seeming idea with very little practical value because the real
world doesn't fit into a small set of neat patterns, no matter how cute you
name them. Overall, they do more harm (usually of the "golden hammer" variety)
than good.

------
barrydahlberg
IMHO design patterns have been a great success because they have caused people
to think about designs and suggested a vocabulary for discussing them.

Whether or not any specific world changing patterns have come out of the
movement doesn't really matter to me. What matters is that the average blub
programmer is just a little closer to understanding that classes are not just
for modelling real world 'things'.

(I'm mostly an OOP programmer, assume something intelligent about functional
programmers etc for me...)

------
simonw
The design patterns I care about are things like "use a template system to
generate HTML", and "create RESTful APIs that respond to GET requests with a
JSON representation of resources", and "write unobtrusive JavaScript". The
same general concept as the boring old Gang of Four patterns (describe a
problem and the pattern used to solve it), but at a much higher level.

~~~
loumf
The GoF book is one pattern language among many. They were concerned with OO
design that is used in a class of programs they had experience with --
basically GUI programs with runtime extension, and with a bias towards
programs that create documents/digital media. There are many other pattern
languages -- I could imagine one for web development that had your three
examples and others.

------
InclinedPlane
Design patterns are universal. You can't avoid using them. The more important
question is whether there are core design patterns which can be used regularly
to improve the quality of software design, and whether or not we have
discovered such a set of core patterns. That question is still, for now,
undecided. Some of the canonical patterns (from the GoF book, for example) are
useful, some have limited utility, overall there's a good body of evidence
that that particular selection of patterns is far from universally applicable
in software development.

------
antareus
Not all patterns are equal. Of the GoF patterns, I'd say there are a few that
are important to know: factory, observer, and visitor spring to mind. (Then
there's the singleton pattern...)

~~~
fragmede
Specifically, examine the singleton's usage pattern, and make sure it's not
just a convenient excuse for a mud-ball of globals.

[http://sites.google.com/site/steveyegge2/singleton-
considere...](http://sites.google.com/site/steveyegge2/singleton-considered-
stupid)

~~~
GFischer
On a followup interview to the GoF, they were in favor of dropping Singleton:

[http://www.informit.com/articles/printerfriendly.aspx?p=1404...](http://www.informit.com/articles/printerfriendly.aspx?p=1404056)

"When discussing which patterns to drop, we found that we still love them all.
(Not really- I'm in favor of dropping Singleton. Its use is almost always a
design smell.)"

~~~
antareus
Yep. The only justifiable use I've run across is internal bookkeeping in a
class library across an API that doesn't provide space for context _and_ you
need lazy initialization.

------
philbo
My experience with design patterns has been that their usage can prevent
people from considering the deeper issue of what it means for a design to be
good. I would far rather work with programmers that have a good grasp of the
five SOLID principles, for instance.

This is not to say that specific patterns are not of merit in the right
circumstances, of course. Just that the notion of design patterns as some kind
of shrink-wrapped, off-the-shelf, one-size-fits-all solution is something I
find mildly alarming.

------
JoeAltmaier
Hm. I've written 100's of thousands of lines of debugged deliverable code, and
the number that matched a design pattern in a book was smallish.

Everything looks like a nail to a guy with a hammer.

------
lars512
If you read the post and substitute "design pattern" for "algorithm", it
sounds quite reasonable. Design patterns are not algorithms though, they're
more like language-specific templates. I don't think they deserve the crowning
glory of being in every CS degree.

------
andrewstuart
If you were recruiting new people into your development team, would you care
about the potential employee's level of knowledge of design patterns?

~~~
autarch
I would probably want them to at least know what they are, and why they are
relevant to a task (or not relevant).

If they'd mostly programmed in modern dynamic languages (Perl/Python/Ruby) I
wouldn't expect them to know most of the individual patterns, since they're
not terribly relevant for those languages.

~~~
kenjackson
I don't do much Python and Ruby. But when I did do Perl there were tons of
design patterns.

And Javascript, another modern dynamic language, also has a lot of design
patterns.

I find it hard to believe that not all languages have their own design
patterns. Just different kinds for solving the types of problems they tend to
run into more often.

------
protomyth
The design patterns implemented by the authors of the API you are using are
probably the most important (e.g. Key-Value-Observor in Cocoa).

------
ryan-allen
This article seems a bit spammy, and doesn't appear to be written by someone
who is a programmer.

