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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Sergey
  • 2,693
  • 3
  • 18
  • 22
  • 86
    If applying a pattern means copying and pasting existing code then you are probably doing it wrong – Dyppl Apr 25 '11 at 04:36
  • 9
    using design patterns != cargo cult programming – jhocking Jan 09 '12 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 09 '12 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 '15 at 18:47
  • 1
    http://programmers.stackexchange.com/questions/9219/are-design-patterns-generally-a-force-for-good-or-bad Related. – Kzqai Sep 14 '15 at 02:07
  • Re your statement: *"when people face a problem and they don't have much time, they try to use a pattern"* - It is the difference between creating a solution, which is a largely unconscious process, and trying to plug together chunks that have worked in the past. If I am trying to drive somewhere, I could get out a map and find the 'best' route, or I could just go off in a direction that has worked for me before (but which might fail this time). Programming is not cut and dried enough that Lego blocks will always work, or be pretty enough for the customer's wants. –  Mar 15 '18 at 13:45
  • Design patterns are the [jōseki](https://en.wikipedia.org/wiki/J%C5%8Dseki) of programming. – Pablo H Sep 02 '21 at 14:30

9 Answers9

293

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • 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 '11 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 '11 at 04: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 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 06 '11 at 18:48
  • 10
    @Jorg: when did the "subroutine call" pattern go away. What do you think a method/function call is? – Dunk Feb 09 '12 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 '12 at 12:43
  • @pdr By telling someone to "Use a strategy for that", aren't you doing exactly the opposite of what you have explained in your answer? Aren't you asking someone to use a design pattern you think fits well for a particular solution? – CKing Feb 26 '13 at 19:06
  • 2
    @bot: I am saying "here's a pattern that solves your problem" as opposed to "ok, here's a problem, I need a pattern for this." Do you see the subtle difference? If there isn't a pattern for a problem, you shouldn't try to force one in; but, if there is, then you should use it to communicate the idea. – pdr Feb 27 '13 at 08:18
  • @pdr The statement "here's a pattern that solves your problem" can be spoken in 3 scenarios. 1. Someone comes to you and asks you whether an existing pattern can solve their problem or 2. You make a suggestion to someone that they can use XYZ pattern to solve their problem or 3. You are talking to the computer. In either case, you are mapping a pattern with a problem statement which contradicts your opening statement - "It's rare that I sit wondering which pattern I should use in a given situation". Your answer is logically incorrect! – CKing Feb 27 '13 at 09:24
  • In case 1, I would suggest that the "someone" is asking the wrong question. The question should be "how do I solve this problem?" If I then communicate a solution using a recognised pattern name (case 2), that's entirely consistent with my answer. I haven't thought "What pattern solves this problem?" I have thought "What's the correct solution? What's the simplest way to convey that solution?" – pdr Feb 27 '13 at 10:26
  • @JörgWMittag It sounds like the pattern is still there, people just have an easier way to write it. For example, suppose there was a language that let you define `public builder class foo {...}` , where all methods are guaranteed to return `this`. It may be institutionalized into the language, but it's still there... – Darien Sep 18 '13 at 00:16
  • @JörgWMittag: "Both of those are now practically extinct since they were absorbed in modern languages." Interesting observation. Some time ago I suggested that object orientation is just a design pattern and was told this makes no sense. But I agree with you: many programming language concepts used to be design patterns in earlier languages that did not support them directly. – Giorgio Nov 02 '14 at 10:07
  • Where I've struggled with design patterns is actually the names. I used to just call the analogical observer a `click callback` on a button, and many years later, my colleagues instead were enthusiastically talking about `button observers`. And I initially found it so stressful to find the discussion revolving around all these new names for things I thought so common, and trivial -- why do we need "flyweight" to avoid duplicating data and just point to or index something shared? At least I often found myself asking such questions... and some of the names always bugged me [...] –  Feb 01 '18 at 03:26
  • [...] like `factory` or `strategy`, both of which flood my mind with imagery like a car manufacturing plant or a grandmaster of chess, both of which are very different and so much more complex in the imagery that fills my brain than, say, merely selecting an algorithm at runtime. So I've always struggled with some of the names, find them visually-heavy and sometimes "too cute" (though I do like ones like command, interpreter, and iterator -- they seem just about right). –  Feb 01 '18 at 03:31
  • But I felt so isolated and lonely for a while when GoF released their book since I didn't share that enthusiasm about how it transformed the workplace and the way we communicated about designs. It wasn't like the techniques were new, and the way some people started asking about the best DP to use instead of just figuring it out bugged me. Now I sometimes appreciate being able to refer people to these names as a shorthand, but I still have never felt 100% comfortable with the names and language, and how it has shaped some young people's ideas about how to design software. –  Feb 01 '18 at 03:34
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.

Rein Henrichs
  • 13,112
  • 42
  • 66
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.

Vitor Py
  • 4,838
  • 1
  • 27
  • 33
  • 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 '11 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 '11 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 '13 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.

hardmath
  • 826
  • 1
  • 8
  • 12
  • 3
    "Anti-pattern" is just a long-winded euphemism for "bad". – Michael Shaw Feb 13 '14 at 00:23
  • 1
    @hardmath "Anti-pattern" means a lot more than just 'bad' – GoatInTheMachine May 30 '17 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 '17 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.

Donal Fellows
  • 6,347
  • 25
  • 35
  • 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 06 '11 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 06 '11 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 06 '11 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?

Gus
  • 368
  • 1
  • 4
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.

Pete
  • 8,916
  • 3
  • 41
  • 53
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.

Tom W
  • 316
  • 1
  • 7
-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.

Jacob Harrington
  • 11
  • 2
    this doesn't seem to offer anything substantisl over points made and explained in prior answers – gnat Nov 02 '14 at 09:03