This week, at the study group, our engineer asked a question: Should we follow the design pattern to design and implement the project from the beginning?
The design pattern mentioned here refers to GoF’s Design Patterns.
Meanwhile, there is a related context which suggests that our coding should follow SOLID principle as much as possible, especially the first S and the second O, anyway.
Since SOLID principle should be followed as much as possible, then the design pattern should also be taken into consideration from the very beginning, right?
No, not really.
What are design patterns?
The design patterns we often talk about actually refer to those solutions defined by GoF, which are designed to solve the problems often faced in object-oriented programming.
When we want the code to be easy to maintain and easy to modify, i.e., the open and closed principle, we abstract the problems through various encapsulation techniques, and eventually become those interesting design patterns.
Did you notice two key points in this paragraph?
- OOP-specific problems
- Ease of maintenance and modification
If your project has just started and there is still a question mark over whether it will be successful or not, why do you need to think about the flexibility in the long term?
If your project requirements are fixed, why do you need to worry about maintenance and modification?
If you’re one of my regular readers, you’ll remember we’ve talked about a similar question before.
Even earlier on, we have talked about another similar issue.
Most of time, I’m on the side of “don’t over-engineering”.
Whether it’s design patterns, clean architecture, or even microservice architecture, they are all means to solve problems, but first, you have to encounter the problem. If you have a clear problem, find the right solution, and don’t do it just for the sake of doing it.
What exactly is a Pattern?
By the way, what is pattern?
As I mentioned at the beginning, the design patterns we often talk about actually refer to the solutions listed in the GoF book.
Pattern is like a “symptom”, when you have a cold over and over again, you will know that you need to drink more water and take more rest, the same is true when we program. When we see a certain problem over and over again, we will naturally have a corresponding solution, but will this solution be the most effective one?
The design pattern is the medicine for that symptom. When we come across a symptom, we will find out the corresponding medicine to solve the problem, and therefore, you should not usually take medicine without thinking about it, right? It’s unhealthy to take medicine when you don’t have symptoms.
In fact, patterns are everywhere.
Object-oriented programming has its patterns, software architecture has its patterns, and even system architecture has its patterns.
For example, the following book should not be unfamiliar to you.
This book may feel a little unfamiliar.
Here is a series of books from Volume 1 to Volume 5.
These books are all about the patterns encountered in various software development contexts, in short, a list of medicines.
If we’re sick, we can get something out of it, but if we’ve never been sick, we don’t even know what they’re talking about, not to mention when to consider the patterns.
Conclusion
Software development is a pragmatic process.
What we are doing is always encountering problems, thinking about them, and finally solving them.
“This may be needed in the future, so I’m ready for it.” I’ve heard this phrase a lot, but in reality, most of these pre-prepared things don’t work. Because requirements are always changing.
But if we find requirements have changed and it’s hard for us to implement them, then it’s not too late to consider what medicine we need to take. This is refactoring.
Source link
lol
