Are design patterns essential for good code? [duplicate]
-
02-10-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Are design patterns (e.g. factory pattern, observer, etc...) required to be known to write good code?
I often have no idea of what people mean when they talk about inserting pattern name here pattern and sometimes I realize I‘ve implemented that pattern without knowing it even had a name.
I‘m a self-taught programmer so I try to learn about patterns as I go, but are they necessary?
I find them over-engineered sometimes, like just fancy design concepts that programmers sometimes overestimate and force themselves to use them even if they can write clean and working code that is however not a common pattern.
Solution
Design patterns are not required in order to write good code.
They are names given to certain known good solutions to common programming problems. Chances are good that you have in fact used some design patterns without known (for example - the iterator pattern is built into several languages as it is so prevalent).
Knowing the names and meanings of design patterns is simply an aid to professional conversation (and for naming of variables and methods) - when you and the other party are familiar with design patterns, it is clearer what is going on.
What you shouldn't do is look for ways to implement a specific design pattern - you should be looking in the other direction - finding the patterns that already exist in the code and optionally, rename the code if they make it clearer.
So, you don't have to study or know the patterns and their names in order to be a good coder - if you are a good coder, however, chances are good that you are already using many patterns without knowing so.
OTHER TIPS
Yes, patterns are essential. I'll refer you to What if I will not use Software Design Patterns? by Eric Lippert in which he points out:
Variables are a design pattern.
Methods are a design pattern.
Operators -- addition, subtraction, etc -- are a design pattern.
Statements are a design pattern.
Values are a design pattern.
References are a design pattern.
Expressions are a design pattern.
Classes are a design pattern.
Everything you do in programming at all times is a design pattern. Most of the time the pattern is so ingrained into your thinking that you've stopped thinking of it as "a design pattern". The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.
This goes to your point of that you've used design patterns without even knowing its name. You've also used ones that you did know had names but didn't realize they were patterns.
The key is how people think about patterns... and to an extent I blame education (or maybe the lack of) at times where they expect Design Patterns to be like Legos - "we'll get a Abstract Factory, and Flyweight, and a Singleton and a Facade... and it will all just fit together." One can often see this in questions asked "What pattern do I need for problem XYZ" before they've really started coding or thinking about the project as a whole.
Looking at the original book A Pattern Language (wikipedia) about building architecture, a Pattern is something that you use to solve a particular design. You want to put a window in a stud wall? Well, then you put in some cripples and a header and a bottom plate and so on (wikipedia). This is a pattern and you do it because you want to put in a window in a wall.
Note that in the above example, the problem came first, then the design pattern. I need this, this is is how I'll fix it. The other way around "I'll put some cripples, bottom plate and so on here so that I have a window because I'll need a window" is the wrong way to go about the pattern of a window. Likewise, it's the wrong way to go about using patterns in software development.
The other thing to realize is that if you have two people working on putting in a stud wall, they can quickly communicate and understand what is going on when they put in a window. They both know and understand the problem and the pattern and how to apply it. The same is again true with software. We've got a problem that we need too many Integer objects being created? We'll put in a Flyweight. And thus, two programers have communicated, and know how to solve the problem because they are able to speak of Patterns.
No. Patterns are best applied to write code that others (and yourself down the road) can understand.
Applying a pattern willy nilly will make it a fancy design concept, but when a pattern fits a problem it is better to use than come up with a creative solution.
Patterns are generally cliches, they work and you likely have used quite a few without realizing it, but this is not an excuse to ignore learning about them as you will find some that you don't know of and it will broaden your own knowledge of programming rather than figuring out everything yourself. As a self-taught programmer this is a vital piece of development to come to terms with
