Design patterns are blueprints – DZone Java

Recently I was checking out DZone for interesting programming articles. One of the articles on the front page stated: Design patterns are not blueprints. If you haven’t already read it, do so now.

So, of course, I got interested and read the text. He belonged to the category of I wrote good code and I’m proud of it. But I would also say that it comes down to tackle well-known and proven programming practices (one of many TDD is bad, Design Patterns are bad, OO is badetc.).

Immediately, I sense objections. The author didn’t outright say “Design Patterns are bad!”; he just mentioned that you don’t have to apply them left and right. Offensive articles tend to use words such as evil, sucksor anti-pattern!

That’s all well and good, but that brings me to the title of this article: “Design Patterns Are Blueprints”, which the author of the opposing article disputes. A model is a proven working method for solving a design problem. It should only be used in this kind of problem – not everywhere possible. Moreover, to say that everything about the model is its implementation is as silly as doing anything else without thinking.

In his case, it would be stupid to define a WiringStrategy interface with a wire() because you would have to add a lot of classes for nothing. The higher level logic would be cluttered with a list of WiringStrategy too generic instances and algorithms. We would abuse a model to gain an artificial advantage over the original solution.

Why wouldn’t the model help? Because the case of the author was not one for which we need a strategy; it needed no algorithm interchangeability or algorithm-caller separation. We would be playing with a list of strategies instead of just code. (Worst-case scenario he could have really messed up the softcoding and externalized the list of strategies to a config file. Luckily he didn’t!) So you should only use the pattern if it corresponds to your case, not in every similar case.

When do you stop using a pattern? When someone looking at and maintaining code sees simple method calls with obvious goals and understands the precedence between them without any patterns. Moving to separate classes and a fixed structure in the name of flexibility would force the poor maintainer to go to multiple places to figure out what the code is doing when it just doesn’t seem worth it.

This article may seem like a separate example, but I have personally witnessed many such serious cases. Sometimes it’s the person who is convinced that design patterns aren’t blueprints, but misusing a term and spreading misunderstandings on a popular site for programmers is somehow okay. Design patterns have their place and shouldn’t be overused, but we shouldn’t redefine well-known and established terms just because we feel like it. Other times, it’s the person who feels the need to stand up to a well-known truth and prove they’re smarter; but I don’t think that was the case this time.

Ultimately, all of our design patterns and best practices are designed to train our minds to write good code. They are not meant to substitute for thought, but we should not redefine them unless we have a very good reason to do so. Also, the best users of design patterns often label their classes AbcFactory or XyzStrategy or AbstractProxyVisitorImpl because they want to express the intentional use of a design pattern (even if it is clearly visible).

As the wise programmer says Not just the simplest thing that works. The simplest good design that works!

PS. This text is not intended to attack anyone personally. I don’t like it when people write things based on false premises.

Abdul J. Gaspar