In the first two years of my work, I wrote code for projects without considering code extensibility, portability, or modularity, which led to difficulties when new features were added or modifications were needed. Today, I’m sharing an article organized by Xiaoyao about design patterns, hoping it will be helpful to everyone.
After working for some years, I often see friends asking whether design patterns need to be learned. It seems that those in embedded development have never encountered a situation where design patterns were necessary, so I have never systematically studied them, but I also know they are important. Over time, I still haven’t learned them.
Here, I would like to share my thoughts and reflections on some issues.
What Are Design Patterns?
Design patterns represent the best practices accumulated by developers, providing optimal solutions to common problems faced during software development.
In other words, through continuous development, different problems or solutions have corresponding methods, and these methods have been summarized into several general patterns that we can apply when we encounter similar situations.
Of course, the major development principles and over twenty design patterns can be found in various references; I won’t elaborate on them here (I have only used a few myself), and it’s better for everyone to study them independently.
Why Are Design Patterns Rarely Used in Development?
In regular project development, we rarely use design patterns. I feel this phenomenon is quite normal; it’s not that design patterns are not used in work, but in most cases, we don’t think that deeply about our projects. More often, we make some requirement changes and overlook the essence.
The purpose of design patterns is to provide extensibility and maintainability, but most of the projects we develop are fixed, with single logic. The modules we develop are not reused in other locations or projects, and the objective is clear: to handle the current business.
Design patterns are seldom used in everyday development, but frameworks are different; frameworks must adapt to different projects, possessing high elasticity and extensibility. They need to fit various environments, so design patterns are omnipresent in framework design.
If you start at a large company or take over a nearly mature project, you will likely be responsible for small modules or specific areas of development; however, in a small company or when starting a project from scratch, we may not be capable of designing an architecture that aligns with the long-term planning of the project, ultimately leading to messy code and poor maintainability.
Therefore, in embedded development, when we have a certain foundation and project experience, we will think, “How important a good architecture is!” or “I need to learn about design patterns properly.”
Do Embedded Developers Need to Learn Design Patterns?
It can be said that design patterns are created for extensibility.
In everyday project business logic code, most functionalities are fixed and specifically designed for that scenario, not appearing in other scenarios. This type of business development does not require design patterns.
However, if requirements change, we generally modify the source code directly, which actually incurs a certain modification cost. Designing a highly extensible architecture for potential future changes in a project also has evident costs, so it’s a trade-off.
Of course, from a long-term perspective, a good design is worthwhile; after all, instead of constantly modifying for new requirements, it’s better to have a one-time solution, allowing developers to work efficiently from various aspects.
In embedded software development, when the software system reaches a certain level of complexity, design patterns become particularly important. Although embedded developers often work with 16-bit/32-bit/64-bit microcontrollers, which may be limited by hardware constraints, microcontroller software can still adhere to the fundamental principles of software engineering for architecture.
From the perspective of code organization, such as componentization, layering, and decoupling, or from a design perspective, such as message queues and event-driven architectures, there are justifiable reasons.
Thus, regarding this issue, it’s best for embedded developers to learn design patterns. I encourage everyone to read more about refactoring, design patterns, and object-oriented C.
How to Learn Design Patterns?
Having discussed so much about what design patterns are, where they are used in embedded systems, and whether they need to be learned, now let’s address how to learn!
I would like to discuss this from several perspectives regarding how to learn design patterns, depending on your level, the problems you mainly solve, and the parts you are responsible for.
If your programming level or learning stage hasn’t reached that point (still learning how to code), it’s natural to feel confused after reading this. At this stage, it’s better to solidify your foundational knowledge, as you won’t need these concepts yet.
If you are primarily solving business logic in projects, there are not many design patterns that can be applied because what is needed is a business model, meaning you can refer to design pattern principles to design your own business model and modify requirements accordingly, which is unnecessary.
If you are responsible for or involved in application frameworks or related areas, it will be very helpful. At this point, the design patterns you choose and how you design them will test your skills.
Of course, regardless of your current level, as long as you have time, you can learn design patterns to improve your skills, but it should be a gradual process.
This learning is also not about mastering everything at once, which is actually very difficult. You might only grasp the surface; it’s generally better to start learning from a pattern related to the problems you are dealing with or commonly encounter, focusing on one at a time and delving deeper.
Most people often mention the singleton, factory, and strategy patterns, for instance, if a function requires support for both serial communication and TCP communication, and it would be best if the caller does not need to know the differences; this is a typical scenario for the strategy pattern.
This common situation can be encountered in many projects, so it’s impossible not to learn. There are also many experience shares and tutorials available online, so it’s unlikely you won’t learn it.
So, do you think design patterns are useful?
Everyone’s situation is different, and the learning process isn’t always the same; the work content will certainly vary. The key point is that as long as you are in this field and writing code, you will generally need to use some of the patterns. Once you learn a few and use them frequently, over time, you will naturally understand.
Reply in the background with 『Embedded Software Design and Development』『Popular Science Knowledge』 to read more related articles.
Welcome to follow my public account, reply “Join Group” to enter the technical exchange group according to the rules, reply “1024” to see more content.
Welcome to follow my video account:
Click “Read Original” to see more shares, and feel free to share, save, like, and view.
