Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

EDIT: 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.

share|improve this question
49  
If applying a pattern means copying and pasting existing code then you are probably doing it wrong –  Dyppl Apr 25 '11 at 4:36
3  
using design patterns != cargo cult programming –  jhocking Jan 9 '12 at 15:51
8  
This question's title can be re-worded as "Is not re-inventing the wheel really essential nowadays?" –  Eric King Feb 9 '12 at 14:55
    
Some developers do not like design patterns because "design patterns force them to think". –  Giorgio May 15 '13 at 12:35
add comment

8 Answers

up vote 154 down vote accepted

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.

share|improve this answer
30  
+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
5  
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 4:59
3  
@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 '11 at 18:48
5  
@Jorg: when did the "subroutine call" pattern go away. What do you think a method/function call is? –  Dunk Feb 9 '12 at 15:55
4  
@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
show 6 more comments

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.

share|improve this answer
2  
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
    
@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 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! –  bot Feb 26 '13 at 19:17
add comment

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.

share|improve this answer
    
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 '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 6 '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 6 '11 at 15:12
add comment

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.

share|improve this answer
    
"Anti-pattern" is just a long-winded euphemism for "bad". –  Michael Shaw Feb 13 at 0:23
add comment

Design patterns are an increase in the expressive power of the common language that we use as software people. This common language is not essential, but it makes many common solutions to problems easier and faster to express. For example, it's a lot easier to talk about Singletons than it is to talk about "classes where we are only supposed to have one instance but which can't be made static and global".

The solutions that design patterns provide are useful, but they are solutions that you've probably already thought of if you faced the problems they solve. A certain level of maturity is required to understand design patterns - if you've never had to solve the problem, you won't see the value or interest in the solution.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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