HMI and design patterns

　　Design patterns are the foundation of good architecture.

　　So what are the specific concepts of design patterns?

　　Design patterns are a set of commonly known, cataloged, and frequently used summaries of code design experience. Design patterns are used to make code reusable, understandable, and reliable.

　　There are roughly three types of design patterns, as shown in the following figure:

　　

　　When we are developing a human-computer interaction interface, we often use the following design patterns consciously or unconsciously:

　　

　　Message interaction typically USES the observer pattern as the message mechanism, with the message driving the entire logic.

　　In order to consider the encapsulation of the program, we will use many ways to hide members that do not need to be exposed, limit calls, and reduce coupling.

　　Some complex special logic can be cleverly managed using design patterns, such as state and command patterns.

　　Of course, there are other HMI design patterns that can be used in the HMI design process, and here are just a few examples that I’ve come up with so far.

　　No matter what the design pattern is, the following six principles should be followed:

　　(1) single responsibility principle. In layman’s terms, a class is responsible for only one responsibility. Why do this? A class, one more function, will be one more change factor. So don’t have one more reason for a class to change, so that it is more stable and the dependent classes are less affected.

　　(2) Richter substitution principle. In layman’s terms, the Richter substitution principle is that a subclass can extend the functionality of a parent class, but cannot change the functionality of the parent class. It contains the following four meanings:

　　Subclasses can add their own unique methods.

　　When a method of a subclass overloads a method of a parent class, the preconditions of the method (that is, the parameters of the method) are looser than the input parameters of the parent method.

　　When a method of a subclass implements an abstract method of a parent class, the postcondition of the method (that is, the return value of the method) is stricter than that of the parent class.

　　(3) the principle of dependency inversion. Definition: high-level modules should not rely on low-level modules, both should rely on their abstraction; Abstractions should not depend on details; Details should rely on abstractions. In general, a program for the interface. This is important. I think this is an important judgment whether the program ape can handle and maintain large projects. If you’re programming to an interface when the engineering code gets bigger and the requirements change, you don’t have to change it around, you can do it by extending new subclasses, because the interface doesn’t change, so the classes that use it don’t have to change.

　　(4) interface isolation principle. Definition: the client should not rely on interfaces it does not need. The dependency of one class on another should be based on the smallest interface. The reason for this is to reduce dependencies and not to have one more reason for a class change.

　　Class A depends on class B through interface I, and class C depends on class D through interface i. if interface I is not the minimum interface for classes A and B, then classes B and D must implement methods they do not need.

　　Solution: split the bloated interface into separate interfaces, with classes A and C building dependencies on the interfaces they need. That is the interface isolation principle.

　　(5) Demeter’s rule. Definition: an object should have minimal knowledge of other objects.

　　The problem: the closer the relationship between classes, the greater the coupling, and when one class changes, the greater the impact on another class.

　　Solution: minimize coupling between classes.

　　(6) open and close principle. Definition: a software entity such as a class, module, or function should be open for extension and closed for modification.
Why it’s a problem？

　　during the software’s life cycle, when the original code needs to be modified due to changes, upgrades, and maintenance, it may introduce errors into the old code, or it may force us to refactor the entire function and require the original code to be re-tested.

　　Solution: when software needs to change, try to do so by extending the behavior of the software entity, rather than by modifying existing code.

　　If you pay attention to these principles in your normal design, your code won’t be any worse. By understanding the common design patterns, your structure will be more rational and easier for teams to develop and maintain. For the introduction of design patterns, you can see the “big talk design patterns“, “headfirst: design patterns” these two books, but the two books more than a lot of salivae, only suitable for the introduction, to in-depth research, suggest or look at the design patterns of GOF classic book “design patterns”.

　　Related posts:

　　Raspberry PI Pico and STONE Display Dazzling Light Control System
Control WS2812B_RGB Lamp by STONE Display Module
Man-Machine Touch Demonstration of Multi Function Automobile Service Equipment
The Structure and Display Principle of High Brightness LCD
Raspberry Pi GUI using STONE HMI Touch Screen Display Module
Ultrasonic module test with STONE LCD module
Automotive Car LCD Screen Project Solutions
By Customer : STONE Intelligent TFT Touch Display Beginners Guide
Fingerprint Identification with STM32 MCU and Serial TFT LCD Module
Record Medical Surgery Notes with STONE Serial LCD Screen