
Software Design Patterns Are Not Goals, They Are Tools - kiyanwang
https://www.exceptionnotfound.net/software-design-patterns-are-not-goals-they-are-tools/
======
userbinator
It probably seems like an obvious statement to a lot of HN, but I have a
feeling that it isn't to the majority of developers, who for some reason
appear to love immense complexity and solving simple problems with complex
solutions. I think a lot of them started with OO, which immediately raises
their perception of what is "normal" complexity --- at that point, they're
already creating more abstraction than is really necessary. Then they learn
about design patterns and all the accompanying "hype" around them, so they
think "awesome, something new and shiny to use in my code!" and start putting
them in whenever they can, I guess because it feels productive to be creating
lots of classes and methods and hooking everything together. It's easier to
dogmatically apply design patterns and generate code mindlessly than to think
about what the problem actually needs to solve it. The result is code that
they think fulfills all the buzzwordy traits of "good software engineering
practice" (robustness, maintainability, extensibility, scalability,
understandability, etc.), but in reality is an overengineered brittle
monstrosity that is only extensible in the specific ways thought of when it
was first designed. That almost never turns out to be the case, so even more
abstractions are added (including design patterns) on the next change, on the
belief that it will help with the change after that, while leaving the
existing useless ones in, and the system grows in complexity massively.

I did not start with OO, I never read the GoF book, and don't really get the
obsession with design patterns and everything surrounding them. I've surprised
a lot of others who likely have, by showing them how simple the solutions to
some problems can be. Perhaps it's the education of programmers that is to
blame for this.

The statement could be generalised to "software is not a goal, it is a tool".

Related article: [https://blog.codinghorror.com/head-first-design-
patterns/](https://blog.codinghorror.com/head-first-design-patterns/)

~~~
TeMPOraL
> _I did not start with OO, I never read the GoF book, and don 't really get
> the obsession with design patterns and everything surrounding them. I've
> surprised a lot of others who likely have, by showing them how simple the
> solutions to some problems can be. Perhaps it's the education of programmers
> that is to blame for this._

Design patterns are mostly crutches for languages that have pretty weak
expressive power. In a powerful language, you don't need most of them.

See also: [http://norvig.com/design-patterns/design-
patterns.pdf](http://norvig.com/design-patterns/design-patterns.pdf), slides 9
and 10.

~~~
chowells
That presentation makes a funny assumption that it's dynamic languages that do
that. Haskell is _nearly_ as far from dynamic as possible, with all the same
advantages w.r.t. patterns.

~~~
kazinator
Haskell needs "zip3" when there are three arguments to zip.

That's a design pattern for optional arguments straight out of ISO C.

~~~
aninhumer
I think it would be possible to create a generalised `zipN` function, using
the Haskell printf trick[0], but it would be a lot of complication for little
benefit. It's rare that you need to merge that many streams at once, and
adding a single digit is not a huge hassle in those cases. Also I'd probably
consider splitting the operation up into stages if I was using anything higher
than `zipWith3`.

[0][http://stackoverflow.com/questions/7828072/how-does-
haskell-...](http://stackoverflow.com/questions/7828072/how-does-haskell-
printf-work)

~~~
drostie
You also have an equivalent on a family of isomorphic types, namely the types

    
    
        forall z. (a -> b -> c -> ... -> z) -> ZipList z
    

This is gotten by taking your `list_a :: [a]` etc. and writing:

    
    
        \f -> f <$> ZipList list_a <*> ZipList list_b <*> ZipList list_c <*> ...
    

You can of course also use Haskell pair-stacks to do all of this, storing (a,
b, c, ...) as the type (a, (b, (c, ... ())))...

------
jrochkind1
YES.

Design patterns are super useful as tools.

As "goals" they are idiotic. I think lots of people that think they are
idiotic have been exposed to them as "goals", or don't realize that's not the
point.

I think there is a larger issue here, which is that many kinds of software
development, including web dev, has become enormously more complex in many
ways than it was when many of us came up.

People coming up now are looking for magic bullets and shortcuts and things
they can just follow by rote -- because they are overwhelmed and don't know
how to get to competence, let alone expertise, without these things.

It's easy for us to look down on people doing this as just not very good
developers -- and the idea of 'software bootcamp' doesn't help, I think it's
probably not _possible_ to get to competence through such a process -- but too
easy to forget that if we were starting from scratch now we ourselves would
likely find it a lot more challenging than we did when we started. There's way
more stuff to deal with now.

"Design patterns" are never going to serve as such a magic bullet or thing you
can follow by rote, and will often make things worse when used that way -- but
so will any other potential magic bullet or thing you can follow by rote.
Software doesn't work that way. It's still a craft.

~~~
orasis
"People coming up now are looking for magic bullets and shortcuts and things
they can just follow by rote"

This is the normal progression of learning. As a beginner, following the rules
by rote is the goal. So, for the newbie that is first being exposed to design
patterns, implementing some of those patterns should be the goal so they can
learn where they fit in the toolbelt.

~~~
mirchiseth
For another somewhat funny take on Design Patterns watch the first two minutes
of this talk from last year DEVOXX

[https://www.youtube.com/watch?v=e4MT_OguDKg](https://www.youtube.com/watch?v=e4MT_OguDKg)

Speaker echoes similar sentiments about design patterns being written by
highly experienced developers and should be used to communicate about code
etc.

------
dantheman
Patterns are from software archaeology, they were naming things that were
commonly seen and what they were for -- they were helping build a vocabulary
to talk about larger constructs.

They are useful if you have a problem and one fits it perfectly, it can help
you start thinking about it -- but it might not be a good fit.

In general we should be keeping software as simple as possible, with the
understanding that it can be changed and adapted as needed. Often large
"pattern" based projects devolve into a morass of unneeded complexity to
support a level of flexibility that was never required.

~~~
mbrock
They are rather from the interest of certain software developers in the work
of the architect and philosopher Christopher Alexander, who saw patterns as
the basic elements of a humane and sustainable style of building and
communicating knowledge about building.

The concept, like so many other concepts, drifted from its origin and became a
more rigid and doctrinaire "system", especially after the misunderstood book
by the "Gang of Four".

In reality, patterns are everywhere in software, whether we call them that or
not.

Game loops, event servers, compilers, map/filter, microkernels, stdin
transformers, for loops over arrays, etc etc etc.

Richard P. Gabriel's book _Patterns of Software_ is freely available and goes
into the history and meaning of patterns. Alexander himself wrote a preface
that's worth reading on its own.

~~~
theoh
This is an aside, but it's significant that Alexander's own architecture is
fairly unsuccessful. His emphasis on loose formal structure and codification
of practices (e.g. built-in window seats, vestibules of whatever it is) is
prescriptive and doesn't help with the real problems of architectural design,
which is something profoundly intuitive, circumstantial and very subtle.
Architectural education is a fascination of mine, partly because it seems to
succeed so rarely.

On a tangent, anyone in London is recommended to visit the end of year shows
of student work at the architecture schools, coming up at the end of June. A
lot of very intriguing and complex activity. (UCL Bartlett, Architectural
Association, London Metropolitan (CASS) etc.) I can't speak for other cities.

~~~
1123581321
This seems opposite to me. Most architecture is prescriptive and there is
little tolerance for Alexander's circumstantial and use-based design. If the
story he recounts in The Battle for the Life and Beauty of the Earth is true,
his preference to use simple materials and let the budget constrain the design
makes him an enemy of building firms which use standards to justify cost
overruns. What did you think about that book?

~~~
theoh
I agree that much building is standardized and conventional. Architecture, for
me, connotes a more ambitious attempt to build creatively and appropriately.

When I say "prescriptive" I suppose I'm referring to the propositional nature
of patterns, like an engineer's rules of thumb. The contrast is not so much
with individual genius and variation as with the maintenance and passing on of
tacit knowledge, which is a mysterious process involving multiple senses and
observational learning.

[http://www.lse.ac.uk/economicHistory/Research/facts/tacit.pd...](http://www.lse.ac.uk/economicHistory/Research/facts/tacit.pdf)

That attitude might sound very conservative, but it's based on my own
experience and not any preference for a particular technology or style.
Alexander is too reductive and abstract; he's not properly in touch with
actual sensory knowledge or craft skills. Or with economical industrial tech,
e.g. the work of Lacaton & Vassal which uses cheap industrial building systems
to create generous spaces.

I haven't read the book you mention. Informing myself about it now.

~~~
1123581321
Let me know how you like it! (I get emailed when someone replies to an HN
comment of mine.)

I think Alexander's patterns rely on tacit knowledge. Many of them involve
designing in a way that real usage can shape the building or land. For
example, the way many colleges will not pave paths until they see the tracks
real students leave between buildings is the sort of thing Alexander has
written about. Thank you for the paper; looking forward to reading it.

~~~
theoh
I've read a brief summary of the World System A and B concept. It seems like
what I have come to expect from Alexander: some reductive rhetoric and claims
that he has rediscovered a true, virtuous way of being. I'm not keen on
encouraging "them and us" thinking, or cultivating the idea of life as a state
of war (the battle for x). I agree in principle that architecture usually gets
imposed on users, when it should be made in a participatory way.

Building "according to the dictates of the human heart" is all very well in
theory, in practice it sounds like it would translate to an ideal of each
family building their own home on a small lot. So where are we in relation to
e.g. the left-right political axis? (It seems like Alexander is proposing a
bottom-up approach to building and planning, in contrast to something imposed
by the state or by corporations.)

If there's one major point I'd make in response to his dualistic picture of
the world, it's that there are potentially varying degrees of citizen
participation in the design process. A pragmatic approach would be to work on
improving participation where possible rather than demonizing the supposedly
pure form of "World System B" in categorical terms.

Here's a theoretical tool which presents a spectrum of participation:
[http://lithgow-schmidt.dk/sherry-arnstein/ladder-of-
citizen-...](http://lithgow-schmidt.dk/sherry-arnstein/ladder-of-citizen-
participation.html)

If there's more, architecturally speaking, to what Alexander is proposing than
just a theoretical opposition between "how things are", and a utopian and
backward-looking idea of "how things should be", I think it's probably a
potential revalorization of the art-historical categories of "linear" and
"painterly".

(For details of "linear" and "painterly" see
[https://en.wikipedia.org/wiki/Heinrich_W%C3%B6lfflin](https://en.wikipedia.org/wiki/Heinrich_W%C3%B6lfflin)
)

In architecture these really correspond to a "structuralist" emphasis on
modularity and interchangeable components on the "linear" side, and an
expressive emphasis on overall form and image-making on the "painterly" side.

To give an example of each in its pure form, Hermann Hertzberger is a linear,
modular, structuralist guy, while Zaha Hadid would be on the painterly end of
things.

Alexander is not proposing Hertzberger-style buildings -- he wants to bring
back traditional architecture -- but essentially I think his background is
structuralist, emerging as he did from mathematics in the 60s. It's this
flavour to his work that makes me feel strongly that he doesn't really care
about tacit knowledge and the intangible, non-propositional aspects of
architecture, the aspects that just cannot be put into words.

Oppositions are hard to avoid in thinking about this kind of thing, but of
course they need to be treated with care to avoid falling into simplistic
thinking.

Approaches to architecture are awash with irrational aesthetic decisions, even
when they claim to be fully rational. There's a famous book from the 60s
called "Architecture without Architects" by Bernard Rudofsky that might be of
interest, as it documents the kind of qualities of traditional anonymous
architecture (not the elaborate, royal or religious kind).

A final thing that comes to mind is the philosophy of Deleuze and Guattari.
They are French post-structuralists. Although, coming from that theoretical
milieu, they come out against the binary "arborescent" nature of simplistic
thinking based on oppositions, they do allow themselves to introduce a
significant contrast: they compare the mode of existence of nomads with that
of the state. They talk about the smooth space of nomads as the origin of the
(improvised) war machine (essentially, of science), while the striated space
of the state is the space of complex social structures and institutions (the
university, for example). Their ideas are very rich and thought provoking,
popular with architects but potentially still strange and radical at the same
time. Their work is evidently a distillation of a huge amount of reading and
contemplation. In my opinion Christopher Alexander's ideas look very tame and
unimaginative in comparison, and the scope of his thinking appears just
disappointingly limited.

Here's a link to a summary which might whet your appetite for Deleuze and
Guattari (their writing is also interesting and compelling, but this PDF
document just gives the bones of one of their main ideas):
[http://www.protevi.com/john/DG/PDF/ATP14.pdf](http://www.protevi.com/john/DG/PDF/ATP14.pdf)

~~~
1123581321
Thanks; really appreciate the reply.

I will go through the links. As you recounted your impression of the A vs. B
system, I remembered that I didn't care so much for the introduction as I did
for the actual story of building Eishin campus. It seems like his most
important principles are to let real usage finish the design and to choose
materials that support that as well as completing the work within budget. My
gut says: how can Alexander be reductive and non-tacit when he is trying to
allow space to be shaped by the people who use it, i.e. directly incorporating
tacit knowledge? There is an "us-vs-them" to believing users know something
designers don't, I suppose, but it's tempered by the humility of believing the
users will do better than the architect advocating for the users. But there
certainly are multiple ways to obtain tacit knowledge and involve it in a
project.

------
prof_hobart
>, if you ever find yourself thinking, "I know, I'll use a design pattern"
before writing any code, you're doing it wrong.

Unless I'm misunderstanding him, I would disagree with this. When you're doing
it wrong is when you use a design pattern without understanding what problem
its solving, and whether you have that specific problem.

To use his tool analogy - if you're a joiner who turns up to a job thinking
"we always need to use a hammer" and start randomly hitting everything, then
you've gone wrong. But equally, if you're halfway through knocking a nail in
with your shoe and think "Oh look, I'm using the hammer pattern now", you're
doing it just as wrong.

If you're looking at two things you need to attach together and you've
considered whether glue, a screw, a nail or something else is the most
appropriate for this specific job, decide it's the nail and _then_ think - "I
need to use my hammer now", then you're doing it right.

~~~
rtpg
I would say that using your shoe to emulate the hammer pattern is a good sign
of flexibility and understanding the heart of the pattern.

The point of the hammer pattern isn't the hammer, but the movements and the
forces applied. In Europe hammers are an axiomatic part of their nails already
so they don't even have a name for the hammer pattern!

On the other hand, if you're with your screw and trying to spin it with the
hammer because someone said use the hammer pattern...

~~~
prof_hobart
It's a good sign of flexibility, but not a good sign of being a professional
on a job.

And it's something I see depressingly often with programmers - tackling
problems that there's a fairly well known existing pattern for, but not being
aware of the pattern and either spending days/weeks rediscovering the pattern
for themselves, or even worse inventing a new and less effective way of
solving it.

------
gwbas1c
Design patterns aren't the problem. All a design pattern is, is a well-known
way of doing something.

When you build a house, do you re-invent how to frame, plumb, wire, and roof
it? No. That's all a design pattern is. Choosing the right design pattern is
akin to making sure that your basement is made out of cement and your walls
framed with wood. (You don't want to put shingles on your countertops!)

The problem is that some developers think they are some kind of magical
panacea without really understanding why the pattern was established and what
it tries to achieve. These are the over-complicated projects that everyone is
complaining about in this thread. (These are the projects where the basement
is made with wood or the concrete walls too thick; or the projects where
someone decided to put shingles on the countertop.)

I try to pick, establish, and follow design patterns in my code. It helps
ensure that I don't spend a lot of time re-learning why some other technique
is flawed; and it helps achieve a consistent style that everyone else on the
team can work with.

------
rootlocus
I found both his definition of the adapter pattern and his example to be a bit
off. In his example, the adapter extends the external interface instead of the
client interface. By definition the adapter must implement the client
interface. It's even in the UML diagram displayed on the website he quotes
([http://www.dofactory.com/net/adapter-design-
pattern](http://www.dofactory.com/net/adapter-design-pattern))

    
    
      > The fact was that I just didn't understand them the way I thought I did.
    
      > To be clear, I've never read the Gang of Four book these patterns are defined in
    

After admitting he has a less than desired understanding of design patterns
(proven by his poor example), he makes bold claims like:

    
    
      > if you ever find yourself thinking, "I know, I'll use a design pattern" before writing any code, you're doing it wrong.
    

I'm having problems taking this article seriously.

------
MoD411
"Software Design Patterns Are Not Goals, They Are Tools" \- I do not
understand why this needs to be said in the first place.

~~~
userbinator
I suppose you haven't seen much of the world of Enterprise Java Applications?

[https://docs.spring.io/spring/docs/2.5.x/javadoc-
api/org/spr...](https://docs.spring.io/spring/docs/2.5.x/javadoc-
api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

Many years ago, I briefly worked in that industry and thoroughly hated the
rigid, dogmatic, extreme overengineering culture and the resulting code it
produced. I'm glad to be away from it all.

~~~
_asummers
Much of the Java+Patterns=<3 stuff came from java lacking syntax for functions
that didn't involve creating an entire anonymous inner class with an apply
function; the Strategy pattern is an excellent example of a pattern that just
goes away when you can pass functions around. There just are not good ways to
express certain solutions without using at least one or two, for any
sufficiently large piece of software, without that syntax. And if your
language is making what you're doing awkward, it's probably not how most
people are going to code. Guava had an entire disclaimer in their functional
documentation that essentially said "whenever you reach into this toolbox,
think about if it's really what you want". Now that Java8 has syntax for them,
we should see people reaching more for Streams and their functional methods.

Now, that said, it's often more tempting and easier to just add complexity,
which results in crazy codebases. It's much harder, especially under pressure
of deadlines, to REMOVE patterns as they don't make sense anymore, which gives
us what people think of as enterprise Java. Not all Java is like that, I
promise.

~~~
mohaine
Sadly, it seems that most of the java devs who created these monstrosities
learned the wrong lessons.

As far as I can tell they seem to think total lines of code was the real issue
(It couldn't be the Abstractions/Patterns, those are good!) and are now on a
kick to move as many lines of code as possible to annotations. I call this
"Annotation based programming" and any new problem starts with a google search
since how any tool kit handles something is pure guesswork.

~~~
_asummers
If you're going to denounce annotations, you must also denounce decorators in
both Python and Javascript. Annotations are a super powerful tool that get
used too much. To borrow from Lisp: data > functions > macros. They should be
the last tool you reach to, in order to remove a bunch of repetition with the
intention of simplifying your code. "Could you do what you're trying to do
with a library of functions that you simply call into? Or some sort of
composition? Or maybe a parent class?" type questions should be asked before
you reach for any sort of metaprogramming.

Take a look at the Retrofit library from Square for a good example of usage of
annotations. To the original Spring link posted, while there's lots of
annotations, they're replacing the XML that used to plague Spring projects,
which I find much more magical. At least I can jump to an annotation's
definition in my IDE.

------
golergka
I have been interviewing a lot of developers recently, and one of the best
questions I've found is to ask them _why_ they have used MVC pattern in the
test assignment (most do). Most of developers misunderstand the question at
first and either start to explain how MVC works or explain how they would've
implemented it without MVC (when you ask people why they did something, they
often take it as "you shouldn't have done it"). But even when I clarify the
question, a surprising number just can't even begin to answer it — instead
they stumble and at best just tell that that's how they have always been
taught to do it.

~~~
sageikosa
That you haven't been up-voted more affirms my belief that you are on the
right track. If they can't explain why they don't know the value of it. If
they don't know the value of it, they can't weigh that value against any
others.

~~~
projektfu
Is "it's the first thing that came to mind" an acceptable answer?

~~~
sageikosa
That's falls somewhere between "because its the way we do things around these
parts" and "it's what we used on my last couple of projects".

Perfectly fine for a certain degree of utility (maintenance, finishing, junior
dev?), not quite so much for a lead, system designer or architect.

------
emodendroket
As far as I can tell design patterns are mostly about taking something simple
and obvious and using terms to describe it that make it obscure and difficult
to understand.

~~~
gnaritas
Patterns are about giving developers a common vocabulary so they can discuss
what they all do without having to go into insufferable detail each time. We
all do lots of the same shit and it's extremely helpful to all use the same
names for those things.

~~~
emodendroket
Why do I have to call it "the strategy pattern?" What was wrong with "passing
in a function?" Giving it a name like that obscures the idea. Yes, I realize
that if you don't have first-class functions you have to work around that with
interfaces or similar, but now we're describing a workaround for a language
limitation, which seems a bit less inspiring than what "design patterns" are
sold as.

~~~
maffydub
I think the word "strategy" encapsulates more about the semantics than
"passing in a function".

For example, the "visitor" pattern could also be described as "passing in a
function", but there's a significant difference: a visitor is intended to be
called on each element of a data structure in turn (i.e. a bit like an
iterator callback), while a strategy defines an algorithm that you're
expecting the caller to select at run-time (e.g. different cipher
implementations).

Syntactically, they may well be the same ("passing in a function") but
semantically, they're very different.

It can be useful to be able to have this shared vocabulary when talking about
designs.

~~~
emodendroket
"Visitor" has always bothered me too. If you look it up it's tons and tons of
text to describe "pass in a function and descend a graph calling it on each
node."

~~~
munificent
That's actually _not_ what the visitor pattern is about, though the way it's
typically presented and the poor name tends to confuse the fact. Visitor isn't
about traversing trees. It's about letting you define class-specific behavior
outside of the definition of the class itself.

It gives you a way to "add a method" to a set of classes without actually
stuffing them in the class definitions themselves.

In practice, most visitor patterns are used with AST classes or other types
that are stored in a tree-like fashion, but that's coincidence. The visitor
pattern itself is really about using virtual dispatch to avoid an ugly and
non-type-safe type switch.

~~~
Munksgaard
So pattern matching?

~~~
munificent
Sort of. It's a way to emulate a simple subset of pattern matching in
languages that lack it.

------
Arzh
This article makes way more sense when he says he never read the Design
Patterns book. If he had, he would know that before he started. They explain
that the book is a collection of patterns that they have compiled from a bunch
of people and from years of experience. The patterns did come about
organically, and they were never meant to be the way to design software. They
were only trying to come up with a common lexicon for something that they were
all already doing.

------
madeofpalk
I'm reminded of a set of tweets from Harry Roberts about whatever new hot CSS
naming convention was popular for the week:

> Modularity, DRY, SRP, etc. is never a goal, _it’s a trait_. Don’t let the
> pursuit of theory get in the way of actual productivity.

> That’s not to say Modularity, DRY, SRP, etc. aren’t great ideas—they
> are!—but understand that they’re approaches and not achievements.

There's nothing super revolutionary about these thoughts, but they've stuck in
the back of my mind for a while now.

[https://twitter.com/csswizardry/status/539726989159301121?re...](https://twitter.com/csswizardry/status/539726989159301121?ref_src=twsrc%5Etfw)

------
awinter-py
design patterns are guru thinking. they're bad ways to describe self-
descriptive tricks like callbacks. don't let a person who talks this way write
docs ever; they'll focus on 'what's being used' rather than what's happening.

design patterns are like when a consultant creates a stupid name for something
that already exists -- the name isn't about expressive power, it's about
declaring ownership so the consultant can sell the 'Consulting Method' to
solve your problem.

when a phenomenon or trick has an easily understood one-word name, don't let a
nonexpert rename it to something nobody understands.

~~~
jrochkind1
Callbacks only become self-descriptive or obvious once you've seen them a
bunch of times.

To a new programmer, say in javascript, who has never seen them before, they
aren't at all self-descriptive or obvious. It is super helpful to have the
term 'callback' to talk about them, and to understand what they are -- say,
just a function you pass in that's then called back or whatever.

Then you'll be able to recognize what it is when you see it in existing
code/api, and how to use it, as well as when to use it when writing your own
code/api. If you really just tossed someone at Javascript and they were a new
programmer and had no idea what a 'callback' was, most people would have a lot
more trouble figuring it out from themselves only from code examples, or would
never think of using it themselves when writing code/api never having seen it
before.

That's all a "design pattern" is. "Callback function" is a common and
successful design pattern in Javascript. (Less common or useful in some other
languages, depending on the affordances of the platform). That's it.

Yes, focusing on "what's being used" instead of "what's happening" is a
problem, yes, thinking you can construct software just by robotically putting
together "design patterns" is a problem.

Design patterns are still a useful and inevitable part of software
development, and recognizing that can make you much more efficient at learning
how to write software, at designing comprehensible and maintainable software,
and at reading other people's software.

~~~
awinter-py
Yes, I meant 'callback' is a better title than 'visitor pattern', not that
callbacks are obvious without explanation.

~~~
jrochkind1
A difference of opinion about what a pattern should be called is not an
argument against the utility of the concept of design patterns.

It's definitely called 'callback' in Javascript, I don't know if that name
would be as obvious or useful in other environments.

------
apo
> Here's the problem I have with design patterns like these [Adapter Pattern]:
> they seem to be something that should occur organically rather than
> intentionally. We shouldn't directly target having any of these patterns in
> our code, but we should know what they are so that if we accidentally create
> one, we can better describe it to others.

It's not clear what the author would have done differently in this example.
It's one thing to raise concerns about pattern-first thinking in general, but
quite another to spell out what exactly is wrong with reaching for the Adapter
Pattern to solve a very specific problem under a given set of constraints. I
can imagine a number of situations in which going straight for an Adapter is
the only sane choice.

I've come to view with great suspicion any general discussion of programming
divorced from its context. Architecture Astronauts and Cowboy Coders can each
do a lot of damage if left to their own devices.

------
badloginagain
Design patterns, OOP, to a large degree programming languages are just tools.
You don't hear of craftsmen saying things like "The only thing you really need
is a hammer. It's been around longer than the other tools and you can use it
on every project". Replace "hammer" with C or Java and you have a legitimate
comment on a score of threads.

 _> What patterns don't help with is the initial design of a system. In this
phase, the only thing you should be worried about is how to faithfully and
correctly implement the business rules and procedures._

I submit that should be your overriding concern at _all_ times, not just the
design phase. If you have to refactor some code in order to extend it, tie it
back to the changed requirement. This forces you to make the least amount of
changes, refactoring the least amount code, breaking the least amount of unit
tests and introducing the least amount of bugs into production.

~~~
arthurvl
Unfortunately looking at just the business rules and procedures leaves the
oft-hidden 'soft' requirements (the -ities) in the dust. Unless you explicitly
state the corresponding requirements, having the business rules and procedures
as your overriding concern will lead to pain. And explicitly stating a
testable requirement for e.g. maintainability or security tends to be quite
hard in practice.

------
EliRivers
While we're here, SOLID is a nice acronym that is helpful as a checklist of
generally good ideas to consider. It's not a law of physics, it's not
compulsory, following it blindly can lead to worse outcomes and if
transgressing it leads to a better outcome (with all things considered) then
it should be transgressed.

------
arxpoetica
Just now realizing there is ambiguity around the terms “design patterns.” Say
it in a different crowd, they'll think you are talking about the kind of
design patterns Brad Frost is writing about.
[http://atomicdesign.bradfrost.com/](http://atomicdesign.bradfrost.com/)

~~~
sageikosa
Maybe there's a common (patterned?) ambiguity to the idea of design patterns?

------
EGreg
Goals should include:

    
    
      1) Solve the problem
      2) Make it maintainable
      3) Make it extensible
      4) Make it scalable (server)
      5) Optimize it for memory, speed
    

So the reason to use an existing paradigm and a well-tested framework is
because it makes the above easier, especially #2. And over time, #2 winds up
saving you a lot resources and probably saves your project from tanking.

Finally, using an existing well known platform also lets you hire developers
who know what they're doing from the beginning, leading to more prosuctivity
and less dependence on any one particular developer. We leverage the knowledge
that's already out there.

------
mirekrusin
His problem may be learning about those concepts from snake-oil sellers - he
mentions he didn't bother to read GoF and gets his knowledge from things like
[http://www.dofactory.com/products/net-design-pattern-
framewo...](http://www.dofactory.com/products/net-design-pattern-framework) .

My advice is to learn from people like Martin Fowler or Kent Beck and if you
want to look at companies, look at something like ThoughWorks.

------
V-2
As pointed out (arguably a bit harshly) in comments under the original
article, this is really a strawman argument. That's because that ol' classical
GoF book on design patterns - which the author admits has not even read -
addresses this concern already. It's still a valid argument, but not exactly a
fresh one. And speaking on the subject without even bothering to read the
piece widely considered as canonical is a bit arrogant.

------
RangerScience
YES

The point of design patterns is a way to describe what you've made succinctly.

NO

When you set out to do something that you don't yet know how to do, having a
crank you can turn to get out functioning code _is a good thing_.

I think what you mean is "Design Patterns are Tools, not Dogma".

Plus, _a lot_ of design patterns only make sense in typed and/or OOP
languages, so under those circumstances, they _can 't_ be applied as goals.

------
bradenb
> In other words, if you ever find yourself thinking, "I know, I'll use a
> design pattern" before writing any code, you're doing it wrong.

I completely disagree... if I'm working with a team. I've spent far too many
hours trying to fix fragile code that comes about as a result of different
devs with different methodologies trying to tie their code together.

~~~
daigoba66
What you're describing sounds more like a teamwork problem - you're likely
either missing someone with the "big picture" who is reviewing code, or a
collaborative code review process.

~~~
bradenb
I would agree that lacking either of those things would cause the problem I
described, but in this case we have both of those.

Most recently, I was the one joining a project after its incipient stage, so I
was not the big picture guy, but the big picture guy chose not to establish
any kind of patterns or standards so when others started joining the project--
even with an understanding of how it should work--suddenly the app had a lot
more functionality but it all performed terribly because of a lack of
uniformity in design. Code review helps, but ultimately because there are no
established patterns there is no justification for telling someone a task
should be implemented differently, right? The only solution I can see is to
establish that justification by trying to get the big picture guy on board
with a massive refactor to establish some standards.

------
exception_e
Kind of relevant to the discussions in this thread:
[https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...](https://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

When I do hit the magic 3 and can justify restructing code, I consider my
options in terms of design patterns (which are very much tools!)

------
matchagaucho
Stated in other terms, patterns are a _means_ to an end. Not the end goal.

Patterns will organically emerge as the result of ongoing refactoring.

------
id122015
I can say the same thing about programming.

Thats why when I read HN I'm trying to understand what are you trying to
achive. Something that goes beyond staying in front of the computer 10 hours a
day.

------
johanneskanybal
"I didn't read the article or the comments but I think you're all wrong, maybe
it's bad upbringing or maybe something else but whatever". ok thanks for
sharing.

------
smoreilly
How can someone doing research on these patterns not have read the most
basic/important piece of literature on the subject?

------
projektfu
When I was in college, I assumed (like most) that patterns were received
wisdom in how to construct software. Then I actually attended a talk with John
Vlissides and realized that patterns were an entirely different thing, closer
to the "archaeological" sense dantheman mentioned. In this way, the study of
design patterns correspond better to the study of rhetoric or poetics in human
language. "Homeric Simile" could be a design pattern in poetry.

In software, some rigidity of expression might be preferred, and so the design
patterns also help us avoid creating new terminology for things that have been
appropriately described.

There are places where each pattern might have utility, and I suppose if there
is any sense to the term "software architecture" it is in the ability to make
sense of what the system should look like in a way that can be explained to
the relevant parts of the team.

There is a tendency, as well, among software developers to think that a
complicated architecture must be the result of countless stupid decisions,
probably made by junior technicians, who were doing things without
understanding what's going on. Thus you find people exhorting others for
simplicity, and acting like they've done their job at that point. But instead,
complicated architecture is the result of compromises and rewrites throughout
the software's life, and attempts to discard those old architectures and start
afresh with similar tools usually result in an initially simplistic, but
ultimately inflexible, design that will eventually evolve into a different
complex architecture.

The Linux kernel is an example of a complicated architecture that was designed
from a standpoint of simplicity initially, and developed its own object-
oriented layer on top of C, with pluggable elements all over, loadable
modules, etc., and millions of lines of code. BSD is smaller and more
coherent, but also much more limited in scope.

There are also examples like Windows NT, which suffered from being the second
system to 3 systems: Windows, OS/2 and VMS. In this kernel, there are so many
design features that were included before implementation, that it seems
incredible it was ever built. But they persisted and made it happen, and even
eventually made it fast, in some cases by working around its design with new
compromises and approaches. Still, it lacks the simplicity of a Plan9 or an
Oberon, but what it doesn't lack is users.

Anyhow, I digress. What is important to me about patterns is the language that
we get from them, and the ability to recognize what's going on in code. They
can provide useful hints about implementation gotchas, and they can also help
people stop reinventing the wheel.

------
bjr-
Read the book. Then read the books that inspired the book.

------
olleicua
THIS

------
rhapsodic
A design pattern is a reusable solution to a recurring _problem_. Too many
inexperienced devs forget that part, and use a pattern where the problem it's
designed to solve doesn't exist. Had the author read the GoF book (he admits
he still hasn't) he might have avoided that pitfall.

~~~
joshdick
Yeah, I can't believe someone would write a blog post about design patterns
without reading the GoF book.

The authors are very explicit in every chapter about what problems are a good
fit for that design pattern.

