Are design patterns really essential nowadays?

Question

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.

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

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 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

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 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

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 7

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.

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.

Answer 9

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.