Are design patterns really essential nowadays? [duplicate]

Question

This question already has an answer here:

• To design pattern, or not to design pattern 10 answers

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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?

Answer 8

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.