Recently I was checking DZone for some interesting programming articles. One of the front page posts read: Design templates are not blueprints. If you haven’t read it already, do so now.
So, of course, I got interested and read the text. It fell into the category of I wrote good code and I’m proud of it. But I would also say that it falls attack well-known and combat-tested programming practices (one among many TDD is bad, Design patterns are bad, OO is bad, etc.).
Immediately I sense some objections. The author didn’t bluntly say “design patterns are bad!” “; he just mentioned that you don’t have to apply them left and right. Attacking articles tend to use words like Wrong, no, Where 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 article opposite contests. A model is a proven and working way to solve a design problem. It should only be used in this kind of problem, not everywhere possible. Also, to say that everything related to the model is its implementation is as stupid as doing anything else without thinking.
In his case, it would be foolish to define a
WiringStrategy interface with a
wire() method 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 misuse a model to gain an artificial advantage over the original solution.
Why would the model not be useful? Because the author’s case was not a case for which we need a strategy; it did not need algorithm interchangeability or algorithm-caller separation. We would be playing around with a list of strategies instead of just code. (In the worst case, he could have made a mistake with the softcoding and externalized the list of strategies in a config file. Good for him that he didn’t!) So you should only use the model that if it corresponds to your case, not in all similar cases.
When do you stop using a pattern? When someone examining and maintaining the code will see simple method calls with obvious purposes and understand the priority between them without any reason. Switching to separate classes and a fixed structure in the name of flexibility would cause the poor maintainer to go to several 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 this is the person who is convinced that design patterns are not blueprints, but abusing a term and spreading misunderstandings on a site popular for programmers is sort of OK. Design patterns have their place and shouldn’t be overused, but we shouldn’t redefine well-known and established terms just because we want to. Other times it is the person who feels the need to stand up against a well-known truth and prove that they are smarter; but I don’t think that’s the case this time around.
Ultimately, all of our design patterns and best practices are designed to train our minds to write good code. They are not meant to be a substitute for thought, but we should not redefine them unless we have a very good reason to do so. In addition, the best users of design models often label their classes.
AbstractProxyVisitorImpl because they want to express the intentional use of a design template (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 just don’t like it when people write things down based on false premises.