Overview of Structural Patterns

Definition and Concept

In embedded software design, structural patterns play a crucial role. They mainly describe how to compose classes or objects into larger structures according to specific layouts to meet complex software design requirements. Simply put, it is akin to building with blocks, treating different classes or objects as building blocks, and combining them according to certain rules and methods to construct a more powerful and well-structured software architecture.

These patterns can help developers better organize code, improve software maintainability, scalability, and reusability. For example, as the scale of software systems continues to expand and functionality becomes increasingly complex, the proper application of structural patterns can clearly delineate various modules, clarify their relationships, and prevent code from becoming chaotic, making the entire software project easier to understand, modify, and upgrade. Thus, it is an indispensable design thought and method in embedded software design.

Classification Introduction

Structural patterns can typically be divided into class-based structural patterns and object-based structural patterns.

Class-based structural patterns mainly rely on inheritance mechanisms to organize interfaces and classes. By creating inheritance relationships between classes, subclasses can inherit attributes and methods from parent classes and can extend or override them according to their own needs, thereby constructing a larger system structure. However, inheritance relationships often lead to high coupling, as subclasses are tightly linked to parent classes, and changes in the parent class may affect subclasses, limiting the flexibility and maintainability of the code.

On the other hand, object-based structural patterns use composition or aggregation to combine objects. Composition refers to combining objects into a tree structure, reflecting the hierarchical relationship between parts and the whole, where the whole object can control the lifecycle of part objects; aggregation, however, represents a relatively loose relationship where part objects can exist independently of the whole object, and the whole object merely references and uses part objects. This way of combining objects through association relationships has lower coupling compared to inheritance relationships, complies with the “Composite Reuse Principle,” and allows software systems to be more flexible in responding to changing requirements, facilitating functional expansion and adjustment. Most common structural patterns belong to object-based structural patterns.

Analysis of Common Structural Patterns

Adapter Pattern

Function of the Pattern

In embedded software design, the adapter pattern plays an important role, primarily used to solve the problem of incompatible interfaces. When different classes or modules have their own independent interfaces that cannot directly work together, the adapter pattern acts as a “converter,” enabling originally mismatched interfaces to become compatible, allowing these classes or modules to collaborate effectively.

For instance, in embedded systems, one often encounters discrepancies in interface formats between different hardware devices. For example, if the output data format of a sensor acquisition module does not match the input format expected by a subsequent data processing module, the adapter pattern can be employed to create an adapter class that converts the data format from the sensor module into a format recognizable by the data processing module, ensuring a smooth data acquisition and processing flow. Furthermore, when it is necessary to apply the driver for an older version of hardware in a new system environment, where the new system has changed the interface requirements for the driver, adapting the old driver using the adapter pattern allows it to function properly in the new system, avoiding the costs of redeveloping the driver and improving code reusability.

Implementation Method

From the perspective of class diagram structure, the adapter pattern typically includes several key elements. First, there is the target abstract class (Target), which defines the interface expected by the client; then there is the adapter class (Adapter), which implements the interface of the target abstract class and contains a reference to the adaptee class (Adaptee), which has the existing interfaces and methods that need to be adapted.

In actual code implementation, there are mainly two ways: object adapter and class adapter (for example, in C language, although there is no strict concept of classes, it can be simulated using structures and function pointers). The object adapter holds an instance of the adaptee class by composition, then calls the corresponding methods of the adaptee class in the implementation methods of the adapter class’s interface, performing necessary data format conversions or logical adjustments to meet the target interface requirements. The class adapter, on the other hand, uses multiple inheritance (in languages that support multiple inheritance; in C, this can be simulated through various techniques) to allow the adapter class to inherit both the target abstract class and the adaptee class, and then overrides the methods in the target abstract class, calling the corresponding methods of the adaptee class in the overridden methods to achieve the adaptation functionality.

Application Cases

In practical scenarios of embedded system development, there are numerous application cases for the adapter pattern. For example, a company originally had a batch of old equipment, whose hardware drivers were written according to the old communication protocol and interface specifications. Later, the company upgraded the system, and the new system adopted a completely new interface standard to interact with hardware devices. To enable these old devices to continue functioning in the new system, developers employed the adapter pattern to write a corresponding hardware driver adapter. This adapter converted the interface data provided by the old device driver into the format required by the new system, allowing seamless integration between old devices and the new system, enhancing the reusability of hardware devices and saving substantial costs associated with replacing equipment.

Another example is in a smart home system, where smart devices produced by different manufacturers have their own distinct control interfaces, some using Bluetooth communication, others based on Zigbee protocols, etc. To allow the central control system of the smart home to manage these devices with different interfaces uniformly, developers used the adapter pattern to create corresponding adapters for each type of device with a different interface, unifying their interfaces into a standard control interface expected by the central control system, enabling easy control operations for various smart devices and significantly enhancing the compatibility and scalability of the entire smart home system.

Example Code of Adapter Pattern

Below is a simple example code of the adapter pattern, demonstrating how to use the adapter pattern in embedded systems to solve interface incompatibility issues.

Example Scenario

Suppose we have an old version of a temperature sensor whose interface is incompatible with the new system’s interface. We will use the adapter pattern to adapt the old sensor so that it can function properly in the new system.

#include <stdio.h>
#include <stdlib.h>

// Old version temperature sensor interface
typedef struct {
    void (*old_read_temperature)(void);
} OldTemperatureSensor;

void old_read_temperature() {
    printf("Reading temperature from old sensor...\n");
}

// New system expected temperature sensor interface
typedef struct {
    void (*read_temperature)(void);
} NewTemperatureSensor;

// Adapter class
typedef struct {
    NewTemperatureSensor new_sensor;
    OldTemperatureSensor* old_sensor;
} TemperatureSensorAdapter;

void adapter_read_temperature() {
    printf("Adapter converting data...\n");
    old_read_temperature();
}

TemperatureSensorAdapter* create_temperature_sensor_adapter(OldTemperatureSensor* old_sensor) {
    TemperatureSensorAdapter* adapter = (TemperatureSensorAdapter*)malloc(sizeof(TemperatureSensorAdapter));
    adapter->new_sensor.read_temperature = adapter_read_temperature;
    adapter->old_sensor = old_sensor;
    return adapter;
}

// Using adapter pattern
int main() {
    OldTemperatureSensor old_sensor = { old_read_temperature };
    TemperatureSensorAdapter* adapter = create_temperature_sensor_adapter(&old_sensor);

    // Use the new system's interface to read temperature
    adapter->new_sensor.read_temperature();

    free(adapter);
    return 0;
}
</stdlib.h></stdio.h>

Code Analysis

• Old Version Temperature Sensor Interface: Defines the interface and implementation of the old version temperature sensor.
• New System Expected Temperature Sensor Interface: Defines the interface expected by the new system for the temperature sensor.
• Adapter Class: Encapsulates the old version temperature sensor and implements the expected interface of the new system. The method in the adapter class calls the methods of the old version temperature sensor and performs necessary conversions.
• Using Adapter Pattern: Through the adapter class, the old version temperature sensor is adapted to the expected interface of the new system, allowing it to function properly in the new system.

By using the adapter pattern, we can effectively solve the problem of interface incompatibility, improving code reusability and system compatibility.

Bridge Pattern

Core Idea

The core idea of the bridge pattern is to separate the abstract part from its concrete implementation part, using composition to replace inheritance, thereby reducing the coupling between the two dimensions of abstraction and implementation. In embedded software systems, as functional requirements continue to increase and hardware platforms diversify, software design often needs to exhibit higher flexibility and scalability. The bridge pattern precisely caters to this requirement, allowing abstract classes and concrete implementation classes to change and expand independently without mutual influence.

For instance, when designing a graphical display system, the abstract concept of graphics (such as the abstract definitions of shapes like circles and rectangles) can serve as the abstract part, while the specific display methods (such as implementations for different hardware screens like LCD screens and OLED screens) can be the concrete implementation part. Through the bridge pattern, we can easily add new display methods without changing the abstract definitions of graphics or expand new types of graphics while keeping a certain display method unchanged, enabling the entire graphical display system to better adapt to different hardware environments and functional expansion requirements.

Application Scenarios

In embedded software, the bridge pattern has a wide range of application scenarios. When faced with different hardware platforms, software needs to run normally on these platforms and possess good portability; the bridge pattern can play a significant role. For example, developing an embedded audio player software that needs to support various audio decoding chips (which have different decoding implementations) and run on different architectures of embedded hardware (such as ARM architecture, MIPS architecture, etc.). In this case, the abstract functionality of audio playback (such as play, pause, stop, etc.) can be the abstract part, while the specific audio decoding implementations and low-level driver operations for different hardware platforms can be the concrete implementation part. By using the bridge pattern, when a new audio decoding chip appears or a new hardware platform needs to be adapted, modifications and expansions can be made only in the corresponding concrete implementation part without affecting the abstract functionality of audio playback logic, greatly enhancing the software’s scalability and maintainability.

Similarly, when facing rapidly changing business logic scenarios, such as an embedded smart monitoring system that has different monitoring modes (like real-time monitoring, timed monitoring, etc.) and different alarm triggering mechanisms (triggering different alarm methods based on different sensor thresholds), separating the abstract logic of monitoring modes from the specific implementations of alarm triggering mechanisms through the bridge pattern allows for flexible combinations and adjustments based on actual application scenarios, quickly responding to changes in business requirements.

Code Example

Below is a simple code example of the bridge pattern in the embedded C programming environment (simplified example, only demonstrating the core idea):

// Abstract class: Shape abstract

typedef struct Shape {
    void (*draw)(struct Shape *);
    struct Renderer *renderer;  // Bridge, points to the specific renderer
} Shape;

// Concrete shape implementation: Circle

typedef struct Circle {
    Shape base;
    int radius;
} Circle;

void circle_draw(Shape *shape) {
    // Perform specific drawing operations through the bridged renderer; assume there is a function to draw a circle
    shape->renderer->render_circle(shape->renderer, ((Circle *)shape)->radius);
}

Circle *circle_create(int radius, struct Renderer *renderer) {
    Circle *circle = (Circle *)malloc(sizeof(Circle));
    circle->base.draw = circle_draw;
    circle->base.renderer = renderer;
    circle->radius = radius;
    return circle;
}

// Abstract class: Renderer abstract

typedef struct Renderer {
    void (*render_circle)(struct Renderer *, int radius);
} Renderer;

// Concrete renderer implementation: LCD screen renderer

typedef struct LCDRenderer {
    Renderer base;
    // May have properties and operations related to the LCD screen
} LCDRenderer;

void lcd_render_circle(Renderer *renderer, int radius) {
    // Specific implementation code to draw a circle on the LCD screen
    printf("Drawing a circle with radius %d on the LCD screen\n", radius);
}

LCDRenderer *lcd_renderer_create() {
    LCDRenderer *lcd_renderer = (LCDRenderer *)malloc(sizeof(LCDRenderer));
    lcd_renderer->base.render_circle = lcd_render_circle;
    return lcd_renderer;
}

In the above code, Shape is the abstract shape, Circle is the specific implementation of the circle, Renderer is the abstract renderer, and LCDRenderer is the specific implementation of the LCD screen renderer. By including a Renderer pointer in the Shape structure, a bridge relationship between the abstract shape and specific rendering implementations is established, allowing for flexible combinations of different shapes and rendering methods, in line with the design concept of the bridge pattern.

Composite Pattern

Characteristics of the Pattern

A notable characteristic of the composite pattern is its ability to compose objects into a tree-like hierarchical structure, where clients can treat both individual objects and composite objects made up of multiple objects uniformly, meaning that their access has consistency. For example, in embedded software, there may be a need to manage complex hardware resources or functional modules, where these resources and modules often have part-whole relationships. For instance, in a sensor network, a single sensor is a basic unit, while multiple sensors can form a sensor group for a region, and multiple such groups can constitute the entire monitoring area’s sensor network. The composite pattern can effectively describe and handle such hierarchical relationships.

It abstracts and encapsulates the hierarchical relationships between objects, allowing external code to operate on these objects without needing to distinguish whether the current operation is on a single basic object or a composite object made up of multiple objects, all of which can be operated using the same interface methods, such as starting, stopping, and obtaining status, greatly simplifying the management and usage logic of complex structured objects.

Practical Applications

In practical development of embedded systems, the composite pattern has many practical scenarios. For example, in a large device control system, there are various sub-devices, such as motors, valves, sensors, etc. These sub-devices can be viewed as individual objects, while a group of related sub-devices in different functional areas can be combined into a larger control unit, and multiple such control units ultimately form the entire device control system. By applying the composite pattern, these devices can be constructed into a tree-like hierarchical structure based on their actual functionality and physical layout.

When it is necessary to perform a startup operation for the entire system, one only needs to call the startup method on the top-level composite object (representing the entire device control system), which will recursively propagate downwards, calling the startup methods of each sub-composite object and individual sub-device objects in order, achieving an orderly startup of the entire system. Similarly, for obtaining device status, performing fault detection, and other operations, a similar unified approach can be adopted, greatly facilitating the management and maintenance of complex device control systems.

For instance, in a smart traffic system, there are numerous traffic lights, cameras, electronic tag readers, etc., distributed across different intersections and road sections. By using the composite pattern, these devices can be organized according to intersections, road sections, areas, etc., making it easier for the traffic management center to perform unified monitoring, scheduling, and configuration operations for the entire smart traffic system.

Advantages of the Pattern

The composite pattern in embedded software design has distinct advantages compared to other object organization methods. From a code maintenance perspective, when the system needs to add or remove a certain child node object (for example, adding a new type of sensor or removing a faulty motor in the device control system), it requires only simple add or delete operations within the corresponding composite object, without needing to modify all places in the entire system that use these objects. Since external code accesses these objects through a unified interface, as long as the interface remains unchanged, the impact on other parts of the system will be minimal, greatly reducing the complexity of code maintenance.

In terms of functional expansion, if one wants to add new functionality to the system, such as adding remote monitoring capabilities to the device control system, it is sufficient to add the corresponding implementation logic in the interface method of the composite object (for example, sending a startup notification to a remote server in the startup method), allowing all objects within the hierarchical structure to possess this new functionality without needing to implement it separately for each individual object, enhancing the efficiency of functional expansion and enabling the software system to respond more flexibly to constantly changing demands.

Decorator Pattern

Main Purpose

The main purpose of the decorator pattern in embedded software design is to dynamically add responsibilities and extra functionalities to objects at runtime while maintaining the original encapsulation of the objects, without causing complex impacts on the inheritance structure of the objects. This makes the software system more flexible in terms of functional expansion. In embedded systems, with the changing application scenarios and the constant updating of user requirements, there is often a need to enhance existing functional modules, and the decorator pattern provides a concise and effective way to achieve this.

For example, a basic serial communication module may initially only have simple data sending and receiving functionalities. However, as project requirements evolve, it may become necessary to perform encryption on the data being sent, or to add checksum functionalities to ensure data accuracy, or to log the data being sent and received. In this case, the decorator pattern can be used to dynamically add these extra functionalities without altering the core code structure of the original serial communication module, meeting the diverse needs of different application scenarios.

Implementation Principle

The implementation principle of the decorator pattern mainly involves creating decorator objects, which implement the same abstract interface as the original object being decorated (or inherit from the same abstract base class; in C, this can be simulated using structures and function pointers). The decorator object holds a reference to the original object being decorated. When the client calls the interface method of the decorator object, the decorator object first performs its additional operations (such as encrypting data, logging, etc.), and then calls the corresponding interface method of the original object, allowing it to execute its original basic functionality, thereby achieving the effect of adding new functionalities without changing the original object’s interface.

Taking the previously mentioned serial communication functionality expansion as an example, suppose there is an original serial communication structure like this (simplified illustration):

typedef struct SerialPort {
    void (*send_data)(struct SerialPort *, char *data, int len);
    void (*recv_data)(struct SerialPort *, char *buffer, int max_len);
} SerialPort;

void serial_send_data(SerialPort *port, char *data, int len) {
    // Actual implementation code for sending data through serial port, e.g., sending data via hardware registers
    printf("Sending original data: %s\n", data);
}

void serial_recv_data(SerialPort *port, char *buffer, int max_len) {
    // Actual implementation code for receiving data via the serial port
    printf("Receiving original data into buffer\n");
}

SerialPort *serial_port_create() {
    SerialPort *port = (SerialPort *)malloc(sizeof(SerialPort));
    port->send_data = serial_send_data;
    port->recv_data = serial_recv_data;
    return port;
}

Now, to add data encryption functionality, we create an encryption decorator structure:

typedef struct EncryptDecorator {
    SerialPort base;  // Inherits from the serial communication structure, maintaining interface consistency
    SerialPort *original_port;  // Holds a reference to the original serial object
} EncryptDecorator;

void encrypt_send_data(SerialPort *port, char *data, int len) {
    EncryptDecorator *decorator = (EncryptDecorator *)port;
    // Perform data encryption operation here; assume encrypt function is a specific encryption implementation
    char *encrypted_data = encrypt(data, len);
    // Then call the original serial object's send method to send the encrypted data
    decorator->original_port->send_data(decorator->original_port, encrypted_data, len);
}

EncryptDecorator *encrypt_decorator_create(SerialPort *original_port) {
    EncryptDecorator *decorator = (EncryptDecorator *)malloc(sizeof(EncryptDecorator));
    decorator->base.send_data = encrypt_send_data;
    decorator->base.recv_data = original_port->recv_data;  // Receiving data can remain unchanged or also be decorated
    decorator->original_port = original_port;
    return decorator;
}

Through this approach, we have dynamically added encryption functionality to the serial communication object using the decorator pattern, and can continue to add other decorators as needed to achieve more functional expansions.

Usage Scenarios

There are many scenarios in embedded software that are suitable for using the decorator pattern. For instance, in data transmission, when there is a need to encrypt transmitted data, add checksums, or compress data, corresponding decorator objects can be created to sequentially decorate the original data transmission object, flexibly combining these functionalities according to requirements. Similarly, in sensor data acquisition modules, when there is a need to perform real-time filtering, unit conversions, and add timestamps to collected data, the decorator pattern can be used to dynamically add these functionalities to the sensor data acquisition object, making the data more suitable for subsequent processing and analysis, and this approach allows for convenient customization according to different sensor types and application scenarios, enhancing software flexibility and reusability.

Facade Pattern

Pattern Introduction

The facade pattern aims to provide a unified, easy-to-use interface for multiple complex subsystems in embedded software. It acts as a “coat” for these complex underlying functionalities, hiding the internal complexities, so that upper-level applications or other modules can use these functionalities without needing to deeply understand the specific implementation details and complex interaction relationships of each subsystem, simply calling through this easy facade interface.

In embedded systems, there are often numerous complex hardware drivers, system configurations, task scheduling, and other subsystems, each with its specific interfaces and operational logic. If upper-level applications interact directly with these subsystems, it results in high coupling in the code, increasing development difficulty, and if any subsystem’s interface changes, it can significantly impact upper-level applications. The facade pattern effectively solves these problems by integrating the functionalities of these subsystems and providing a high-level, unified interface, improving the maintainability and scalability of the software.

Functional Manifestation

For example, when operating hardware drivers in embedded systems, it may involve a series of complex steps for initializing and reading/writing multiple different hardware devices (such as SPI interface sensors, I2C interface EEPROMs, GPIO-controlled peripherals, etc.). Through the facade pattern, a hardware operation facade class can be created, encapsulating the operation methods for various hardware device drivers. For instance, there could be an init_all_hardware() method that can initialize all hardware devices at once, a read_sensor_data() method that reads data from an SPI interface sensor and performs necessary data format conversions before returning it to the upper-level application, and a write_data_to_eeprom() method that easily writes data to an EEPROM.

For system configuration, suppose the system has multiple complex configuration items such as network configuration, clock configuration, interruption configuration, etc. The facade pattern can provide a configure_system() method that internally calls the relevant functions of each subsystem in the correct order and logic to complete the entire system configuration work. In this way, developers only need to call the simple methods provided by the facade class when writing upper-level applications to accomplish complex hardware operations and system configuration tasks, significantly improving development efficiency while also reducing the likelihood of errors.

Code Display

Below is a simple example code demonstrating how to use the facade pattern in embedded systems to simplify hardware operations and system configurations.

#include <stdio.h>

// Hardware driver interfaces
void init_spi_sensor() {
    printf("Initializing SPI sensor...\n");
}

void init_i2c_eeprom() {
    printf("Initializing I2C EEPROM...\n");
}

void init_gpio_peripherals() {
    printf("Initializing GPIO peripherals...\n");
}

void read_spi_sensor_data() {
    printf("Reading data from SPI sensor...\n");
}

void write_data_to_i2c_eeprom() {
    printf("Writing data to I2C EEPROM...\n");
}

// Facade class
typedef struct {
    void (*init_all_hardware)(void);
    void (*read_sensor_data)(void);
    void (*write_data_to_eeprom)(void);
} HardwareFacade;

void init_all_hardware() {
    init_spi_sensor();
    init_i2c_eeprom();
    init_gpio_peripherals();
}

void read_sensor_data() {
    read_spi_sensor_data();
}

void write_data_to_eeprom() {
    write_data_to_i2c_eeprom();
}

HardwareFacade* create_hardware_facade() {
    HardwareFacade* facade = (HardwareFacade*)malloc(sizeof(HardwareFacade));
    facade->init_all_hardware = init_all_hardware;
    facade->read_sensor_data = read_sensor_data;
    facade->write_data_to_eeprom = write_data_to_eeprom;
    return facade;
}

// Using facade pattern
int main() {
    HardwareFacade* hardware = create_hardware_facade();

    hardware->init_all_hardware();
    hardware->read_sensor_data();
    hardware->write_data_to_eeprom();

    free(hardware);
    return 0;
}
</stdio.h>

Code Analysis

• Hardware Driver Interfaces: Defines functions for initializing and operating different hardware devices.
• Facade Class: Encapsulates the operation methods for various hardware device drivers, providing a unified interface.
• Using Facade Pattern: Through the simple methods provided by the facade class, complex hardware operations and system configuration tasks are accomplished.

By using the facade pattern, we can effectively simplify hardware operations and system configurations in embedded systems, improving code maintainability and scalability.

Considerations for Choosing and Applying Structural Patterns

Factors for Selection

In embedded software development, choosing the appropriate structural pattern is crucial, requiring a comprehensive consideration of multiple factors.

First is the real-time requirements of the project. If embedded software is applied to scenarios with extremely high real-time response requirements, such as real-time monitoring and feedback systems in industrial control or anti-lock braking systems (ABS) in automotive electronics, patterns like the interrupt pattern that can quickly respond to external events are more suitable. The interrupt pattern allows the system to pause the current task immediately when an event occurs, handle the urgent interrupt event, and then return to continue executing the original task, ensuring the system’s real-time performance. In contrast, for scenarios with relatively lower real-time requirements, such as data processing and background task management, patterns like the facade pattern that can provide a unified interface for managing multiple subsystems or modules can facilitate orderly data processing and operational coordination.

Next, resource limitations must also be considered. Embedded systems often face constraints in terms of memory and CPU processing capabilities. If resources are quite limited, for instance in small smart home sensor nodes, the flyweight pattern is a good choice. The flyweight pattern can reduce the number of objects in memory by sharing the same or similar object states, saving memory overhead. Conversely, if resources are relatively abundant, such as in large embedded server devices, developers can opt for patterns like the composite pattern that enhance system extensibility and flexibility, facilitating subsequent functionality additions and module expansions.

Functional complexity is also a critical factor. When software functionality is relatively simple, such as implementing a single function in a small embedded device (like a simple electronic thermometer), complex structural patterns may not be necessary, and a simple layered architecture or basic procedural code organization may suffice. However, when faced with complex embedded systems, such as smart medical devices involving data acquisition, processing, storage, display, and interaction with external systems, it is necessary to employ patterns like the bridge pattern and decorator pattern to reasonably decompose, combine, and dynamically expand complex functionalities, making the relationships between various functional modules clearer and facilitating development, maintenance, and upgrades.

Additionally, the characteristics of the hardware platform will influence the choice of structural patterns. Different hardware chips and interfaces have their own characteristics; for example, some hardware supports multi-threaded parallel processing, so when designing software, it may be beneficial to adopt structural patterns that fully utilize this parallel capability, such as concurrency-related patterns. Conversely, if hardware resources are relatively singular and computational capabilities are limited, more lightweight and simplified patterns should be chosen to avoid excessive resource consumption and complex logic processing.

Application Considerations

When applying structural patterns in embedded software, there are several key considerations to keep in mind.

On one hand, it is essential to avoid over-design that leads to increased code complexity. Sometimes, developers may introduce too many complex structural patterns in pursuit of software extensibility and flexibility, making originally simple functionality implementations convoluted and difficult to understand, significantly increasing code maintenance costs. For instance, in a small embedded lighting control module, if the goal is merely to implement simple switch and brightness adjustment functionalities, overly utilizing various design patterns to construct the code structure may complicate subsequent modifications and debugging. Therefore, it is crucial to select patterns reasonably based on actual needs, ensuring that the introduction of design patterns genuinely brings benefits rather than merely adding complexity.

On the other hand, compatibility between patterns must be considered. In an embedded software project, multiple structural patterns may be used simultaneously, and attention needs to be paid to whether they can work well together. For example, after employing the decorator pattern for functional expansion of a certain module, if it needs to be integrated into a unified interface system provided by the facade pattern, it must be ensured that the decorated functionality still meets the facade pattern’s interface requirements, avoiding calling conflicts or logical inconsistencies.

Moreover, the impact on hardware resources must be considered. Different structural patterns have varying resource consumption during runtime; for example, some patterns may increase memory overhead for storing intermediate data or object relationships, while others may increase CPU computation for handling complex logical judgments and object interactions. It is vital to evaluate whether these resource consumptions are within the acceptable range for the embedded system, preventing performance bottlenecks or resource depletion issues due to the application of patterns.

Additionally, the familiarity of team members with structural patterns is also crucial. If team members do not have a deep understanding of the chosen patterns, misuse or ineffective application may occur during development and maintenance, leading to confusion and inefficiencies.