123

I was reading "Coders at Work" and have faced the fact that some of the professionals interviewed in the book are not so enthusiastic about design patterns.

I think that there are 2 main reasons for this:

  1. Design patterns force us to think in their terms. In other words, it's almost impossible to invent something new (maybe better).

  2. Design patterns don't last forever. Languages and technologies change fast; therefore, design patterns will eventually become irrelevant.

So maybe it's more important to learn how to program properly without any particular patterns and not to learn them.

The point also was that usually when people face a problem and they don't have much time, they try to use a pattern. This means copying and pasting existing code into your project with minor changes in order to get it working. When it's time to change or add something, a developer doesn't know where to start because it's not his code and he's not deeply familiar with it.

Improve this question
7
  • 86
    If applying a pattern means copying and pasting existing code then you are probably doing it wrong
    – Dyppl
    Apr 25, 2011 at 4:36
  • 9
    using design patterns != cargo cult programming
    – jhocking
    Jan 9, 2012 at 15:51
  • 13
    This question's title can be re-worded as "Is not re-inventing the wheel really essential nowadays?"
    – Eric King
    Feb 9, 2012 at 14:55
  • 2
    Design patterns force us to think in their terms - if you let them. Awareness of patterns allows me to consider possibilities for a given design problem. Often it's like reading a restaurant menu... "no, no, interesting, no, hmm, a-ha!". Further, modern language features often make the specific pattern diagrams, codified decades ago, archaic.
    – radarbob
    Sep 13, 2015 at 18:47
  • 1
    programmers.stackexchange.com/questions/9219/… Related.
    – Kzqai
    Sep 14, 2015 at 2:07

9 Answers 9

Reset to default
294

For my money, I think everyone's missing the point of design patterns. It's rare that I sit wondering which pattern I should use in a given situation. Also, I was using most of those patterns long before I knew they had names.

The power of design patterns is in communication. It is much quicker for me to say "use a Strategy for that" than to describe in detail what I am suggesting. It is much easier for us to debate the benefits of fat domain models vs. transaction scripts if we all know what those two terms mean. And so on.

And most powerfully of all, if I have named a class FooBuilder then you know that I'm using the Builder pattern to generate my Foo.

Even if you don't know what I'm talking about when I say "Observer pattern is ideal for that," you will be able to go off and google it pretty easily.

In that sense, the power of design patterns will never fade.

Improve this answer
14
  • 57
    +1 for "I was using most of those patterns long before I knew they had names." They've all been around a long time, just without the patterns nomenclature. Back in 1991, I was writing singletons in C, and showed one to a more experienced programmer who'd never seen it before and thought it was pretty nifty.
    – Bob Murphy
    Apr 24, 2011 at 17:54
  • 8
    However, patterns also go away. In the 1950s, "subroutine call" was a pretty popular pattern. In C, "object" is a (somewhat) popular pattern. Both of those are now practically extinct since they were absorbed in modern languages and (in the case of subroutines) even into the instruction sets of modern CPUs.
    – Jörg W Mittag
    Apr 25, 2011 at 4:59
  • 11
    @Bob Murphy: Argh Singleton :( :( @pdr: exactly, patterns are about communication about programming. Applying a pattern because it almost fits is the biggest mistake one can make, and therefore design reflection should not be done in terms of patterns, they should only enter the design when it comes to explaining what you thought about: "It's almost like a <pattern> except that I have tweaked ..." I think that the very GOF acknowledge it themselves: the patterns are trimmed down / simplified visions, they need be adapted to the particular situation.
    – Matthieu M.
    May 6, 2011 at 18:48
  • 10
    @Jorg: when did the "subroutine call" pattern go away. What do you think a method/function call is?
    – Dunk
    Feb 9, 2012 at 15:55
  • 12
    @Dunk: It depends on the languages you are using, of course. I don't know what languages you are using, but in all of the languages I am using today, subroutine calls are a built-in language feature, not a design pattern. However, in C for example, method call is a design pattern, whereas in Java it is a built-in language feature.
    – Jörg W Mittag
    Feb 10, 2012 at 12:43
19

Patterns serve two primary purposes:

  • Resolving tensions predictably: Patterns are designed to resolve a certain set of tensions in a way that is known to work. Kent Beck, author of Smalltalk Best Practice Patterns, describes patterns as a way to repeat the decision an expert would make in similar circumstances. As long as the tensions remain the same (and they often do), the patterns that resolve them will remain useful.

  • Communication force multiplier: Patterns allow us to say a lot with a little. They leverage a small set of powerful, well understood concepts that are applicable in a wide variety of problem spaces. @pdr's answer is dead on about the communicative value of patterns.

Improve this answer
1
  • 1
    What do you mean with tensions?
    – StackedCrooked
    Oct 1, 2020 at 11:04
13

I think the affirmative that design patterns hinders innovation is completely false. You should know wherever already exists so you don't need to reinvent the wheel. For being temporary, patterns as a whole applies to OOP systems and are not linked to any particular platform or language.

Now, what I dislike when people talk about patterns is that some people have a kind of obsession with them. I once had a client to ask me "to include at least two more patterns" (WTF?!) since due to the lack of buzzwords in my code it didn't look enterprisy enough.

Improve this answer
3
  • 3
    My experience is that well-written code conforms to multiple design patterns precisely because they describe good practice. Thus to satisfy your client, it should have been just a matter of spotting which ones you were already using and putting their names in the docs. Easy!
    – Donal Fellows
    Apr 24, 2011 at 15:34
  • 1
    @Donal Fellows That's what I did :) I ended up finding spotting patterns and naming them, giving the project a happy ending. My biggest problem is that it was a very, very small project (about a week of work) and very straightforward: it read data from a freaky data format, did a couple of transformations, graphed the data and sinked it into a database.
    – Vitor Py
    Apr 24, 2011 at 15:39
  • @Vitor I totally agree with you. I personally know people who think that looking out for a design pattern that fits your problem/scenario is a bad idea! They prefer reinventing the wheel. I fear that they may wake up one day and ask me not to use the Java IO classes and write my own IO handlers!
    – CKing
    Feb 26, 2013 at 19:17
8

Perhaps the concept of anti-patterns is germane. I don't think of studying design patterns as the critical step to becoming a software engineer. Software design is important, often reserved as the prerogative of the software architect on a project, but realistically something that can be hammered out by consensus in the proverbial "well gelled" team.

But design patterns and anti-patterns form a resource for those discussions. One needs to appreciate the lessons of things that worked well (or not) and how to capitalize on (or mitigate) the consequences of design choices. A good team could come up with their own vocabulary for such discussions, but it's really not such a bad thing to reference the defacto standards worked out by authors who've been there, done that.

Improve this answer
3
  • 3
    "Anti-pattern" is just a long-winded euphemism for "bad".
    – Michael Shaw
    Feb 13, 2014 at 0:23
  • 1
    @hardmath "Anti-pattern" means a lot more than just 'bad'
    – GoatInTheMachine
    May 30, 2017 at 12:49
  • 2
    @GoatInTheMachine: I agree, that was a Comment on my post. While anti-patterns are examples of what to avoid, they have characteristic traits that make them attractive design choices. Sometimes consciously following an anti-pattern, knowing its shortcomings and traps, is reasonable.
    – hardmath
    May 30, 2017 at 12:55
4

There are two kinds of design patterns:

  1. Universal patterns, which are much more about how to organize complex programs so that you can understand them at all. These aren't going away, though more examples of them may be discovered.
  2. Situational patterns, which are so bound into the particular forces induced by the constraints (e.g., the programming language) that when those forces change, they become irrelevant.

OK, arguably all patterns are somewhat situational, but with some the forces are from the real world and with others the forces are from the tools. Tools change far faster than the real world.

Improve this answer
3
  • All patterns are defined by the way they resolve a certain set of tensions. As long as the tensions are the same (and they frequently are, that's why they're patterns), the patterns will remain useful.
    – Rein Henrichs
    May 6, 2011 at 15:06
  • @Rein: But the forces that create the tensions can be internal or external. Different languages have different internal forces (e.g., patterns relating to interfaces are more relevant for Java than for C++ due to the different tensions in their class systems).
    – Donal Fellows
    May 6, 2011 at 15:10
  • Definitely. A glance through Implementation Patterns (Kent Beck's Java patterns book) shows a pretty even distribution between general purpose patterns and those that are more specific to the characteristics of Java. Comparing that book to Smalltalk Best Practice Patterns is also revealing.
    – Rein Henrichs
    May 6, 2011 at 15:12
3

Reading about design patterns is like learning mathematics instead of reinventing them. None is keeping you from making a great progress in a certain field once you have a solid understanding of what went before. Do you think Rieman never read Euclid?

Improve this answer
1

There is benefit to design patterns when they reduce the amount of time your colleagues or customers spend thinking "How does this work?". Even though there's no sense in enforcing a standard for the sake of standardisation, if there is one common and well-understood way to do something, whenever a coder looks for that pattern expecting to find it and does, you have made their and your jobs easier.

Improve this answer
1

I believe that the gang of four themselves classify design patterns as

a common solution to a commonly occurring problem*

So yes, the patterns are relevant when the same type of problem occurs. And this brings us to a problem with the term "Design Pattern". A pattern is something recognizable that occurs repeatedly. So in reality there is not a pattern of designs, there is a pattern of problems.

Some programming languages may have native solutions to some of those problems. The "Design Patterns" book itself mentions that the visitor pattern is of little value if you are using CLOS, as multi-dispatch is natively supported by CLOS, the very problem that the Visitor pattern is trying to solve.

Also, the .NET framework has a build in event mechanism for publishing events to multiple listeners, making the Observer pattern less relevant in this context.

The change from desktop applications to web applications** also change the type of programming problems we have to solve. Many of the patterns in the book "Design Patterns" are relevant for desktop applications, but not so much for web applications. Of course, with single page apps, these patterns may be relevant again on the client-side.

But the design patterns, and books like "Design Patterns", or "Patterns of Enterprise Application Architecture" are of huge value when you are a novice programmer and faced with a new type of problem for the first time; as I was the first time I was asked to implement Undo functionality. Had it not been for the "Design Patterns" book, my implementation would probably had been something like storing a snapshot of the data after each state-changing operation*** - a very error prone, and horribly inefficient, approach.

So yes, some of the pattern become less relevant over time, and as you become an experienced programmer, you think less about them. But to a novice, they are valuable, as long as you remember that they are the means to solve a problem - and not a quest to use as many as possible.

* quote may not be 100% accurate as it is taken from memory

** in my experience, it is getting very common for enterprises to choose web delivery mechanisms for internal line-of-business applications.

*** after learning functional programming and functional data structures, then that might actually be the way I would solve it today.

Improve this answer
-3

Slavish adherence to design patterns can be detrimental - patterns are documented solutions to common problems, but they are not instruction manuals. However, just because they are discussed at length and, in some cases, applied outside of effective problem domains doesn't mean they hold no value whatsoever. They are a set of principles - call it a framework - to draw upon when designing a program's architecture, allowing for the architect to give an impression of how he/she would like to see the solution work. A good development team views them as a basis for functionality, rather than a functional specification.

Improve this answer
1
  • 2
    this doesn't seem to offer anything substantisl over points made and explained in prior answers
    – gnat
    Nov 2, 2014 at 9:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.