

Design patterns are just tools - kossmoboleat
http://timbenke.de/?p=457

======
raganwald
I can't help but feel that this article sorta has the surface explanation of
design patterns kinda right, but missing the essntial properties.

Design patterns are solutions to recurring problems, but it's important to
note that they are not the only solutions, and also that the "commonly
recurring problems" are highly context dependent.

Most of the OOP problems go away if you use more flexible programming
languages or paradigms. New meta-patterns like DCI also invalidate the
"recurring problems."

Thus, the critical thing to recognize is that the expression "commonly
recurring problems" is a trap, in that it is easy to assume that it is normal
or expected for those problems to occur, when in actuality they occur as a
consequence of large architecture decisions that can and perhaps should be
made in such a way as to eliminate those problems outright rather than solve
them.

None of the aforementioned invalidates the concept of design patterns, however
I feel it is difficult to say they are "just tools" as if it's perfectly
reasonable to expect to have to use them on a regular basis as if programmers
have no say in the matter of whether the need for those tools will or won't
apply.

~~~
ExpiredLink
> Most of the OOP problems go away if you use more flexible programming
> languages or paradigms.

Spare us the myth. This isn't reddit.

~~~
raganwald
Ironically, your comment is rather reditesque in that it piles abuse upon my
comment without actually providing an argument against it.

Perhaps you have something specific to share about why that or any other point
is wrong? Perhaps an interesting viewpoint on myths and how they take hold?

~~~
true_religion
One myth I can think of is... most people believe that current design patterns
originated in Java, or if not Java then C.

This is primarily because of the languages books like Gang of Four use to
illustrate design patterns.

In reality however, most design patterns date back to Smalltalk which
(ignoring multiple-inheritance for the moment), provides the most flexible and
dynamic representation of objects that I've seen to date.

\----

Another myth is that design patterns were invented.

The the Gang of Four can be quoted as saying they merely are documenting
patterns that will naturally occur in the course of writing code. If you use
run-time-binding to determine an objects inteplementation, then
congratulations you have Inversion of Control whether you want to call it that
or not.

The whole purpose of design patterns is to give us a common language so we
don't have to describe our code, but can simply call it by name.

~~~
raganwald
I agree with what you've said here. I actually use ST to illustrate the
relationship between patterns and languages. "Fluent Interface" is the name of
a pattern wherein methods that are executed for their side-effects return the
receiver, and callers then chain methods to a single receiver. This encourages
writing many small methods while keeping code clear.

It is not necessary in ST, because ST's syntax includes the semicolon operator
for cascading messages to a single receiver. In effect, the pattern is "baked
into the language."

------
mas644
Even before I ever read GoF, I found myself using their design patterns in my
object-oriented code (i.e. "reinventing" what already existed). At the time I
didn't think it was any magic feat, it's just the way I organized the code.
It's nothing surprising, all OOP developers end up doing this -- the
abstractions provided by an object-oriented language naturally lead to the
design patterns we see in the GoF book. In fac,t in the introduction of the
book, the authors describe how the patterns came from existing, real-life
software which they found worked well in practice. Reading GoF is useful to an
OO programmer because whenever they encounter a difficult problem, there's
usually a "pattern for that". Oh I need to manage complex states and state
transitions - use a "state pattern". I need to route messages to any object
that desires the message feed - use an "observer pattern".

As the article states, GoF patterns are a tool and shouldn't be treated
anything more or less than that. I've worked with developers who treat design
patterns with religious sanctity and their designs are convoluted with forced
GoF patterns. The result is bloated code that is difficult to follow. Likewise
I've worked with developers who think they're a scam and prefer to "cowboy"
their own solution which either ends up reinventing a design pattern or just
being plain ugly.

I saw some comments in this thread implying how language paradigms other than
OOP (primarily functional) eliminate the need for many of the GoF design
patterns. This is true, but it doesn't mean that functional (or whatever
paradigm) languages do not have design patterns -- they have their own design
patterns as well. For example, the concept of a "monad" can be considered a
design pattern to implement side-effects in pure functional languages which
lack that feature. Some design patterns transcend language paradigm, for
example, Model-View-Control (MVC) is universal to procedural/imperative,
functional, and object-oriented code. Design patterns also exist for
concurrent computation -- a great example is "The Little Book of Semaphores"
(<http://www.greenteapress.com/semaphores/>). The book details multiple
"design patterns" for solving common problems with concurrent computation in
languages that provide semaphores and threads as the primitive concurrent
computing abstractions. However, to help make the point of the other
commenters -- using a language designed for concurrency (e.g. Erlang)
eliminates the need for a lot of these design patterns. On the flip side,
using something like Erlang introduces a whole new set of problems meaning you
need a whole new set of design patterns!

What I think was revolutionary about GoF was the coining of the term "design
pattern". It's analagous to the concept of "algorithm" but not quite...it's
more general than that. What's beautiful about the term is that it's
applicable to more than just programming, but rather any sort of engineering,
design, or problem solving. As the author of the article demonstrated, there
are even architectural "design patterns". In any field, you'll have design
patterns (they may not call them that) and books on them that predate GoF.
However, the way GoF documented them as wonderfully and clearly as they did in
their book...it's just beautiful.

~~~
gruseom
_As the author of the article demonstrated, there are even architectural
"design patterns"_

Even? Alexander invented them. He also disowned their use in software -
something you'd think software pattern advocates would pause to consider, but
never do.

------
ericHosick
Frameworks, languages, APIs, compilers, design patterns, best known practices,
Agile, UML, TDD, BDD, debuggers, etc. are all tools.

They are tools used by software engineers to solve problems.

The unfortunate thing is that many software engineers fail to realize these
are just tools and confuse them as being the ends as opposed to being the
means.

~~~
grovecai
>The unfortunate thing is that many software engineers fail to realize these
are just tools and confuse them as being the ends as opposed to being the
means. Sometimes confusion may be good for engineers. If all engineers can
clearly realize that they are just tools, it may frustrate someone's interest.
With interest, we are happily using tools.

------
manojlds
I recommend "Recfactoring to Patterns" book - the book says that Design
patterns are just tools from the get go.

