1. Introduction

Modular programming design refers to dividing a large program into several smaller program modules according to functionality during program design, with each small program module completing a specific function and establishing necessary connections between these modules to complete the entire functional program design method through mutual cooperation.

For example, building blocks can be combined into any shape we want using individual block modules, and different shapes can be formed by using the same block modules.

2. Why Modularize

Why modular programming design? This needs to start with the benefits of program modularization! Only by understanding its advantages can we better achieve modular programming.

1. Reduce the complexity of program design

It is beneficial for program design and debugging, with relatively independent functions and clear structure; mainly encapsulating implementation details and providing usage interfaces.

1. Provide code reusability

Ready-made program code can be directly transplanted into another project, modified easily, or even used without modification, and multiple module programs can be combined to complete a new function; this is also the greatest significance of modularization.

1. Facilitate function maintenance and expansion

Once a problem arises, it can quickly locate which module has the issue.

1. Program structure is clear at a glance

It can show which drivers are used in the program, what peripheral modules there are, and what functions are generally present.

1. Ensure system stability

The module program has been repeatedly verified through previous projects, with high stability, and is more stable to transplant in new projects than to rewrite.

1. Facilitate team development

Each module has independent functions, which is conducive to task decomposition, team division of labor, and each implementing corresponding functions, and can be tested and verified separately.

3. How to Split Modules

The basic idea is to decompose from top to bottom, gradually, and divide and conquer, that is, to divide a larger program into smaller modules according to function; for example, a handheld remote control, the main function is human-computer interaction, and there may also be parameter settings, etc., so we can decompose downwards to obtain the following modules:

When splitting modules, the following main principles should be noted:

1. Module independence

The principle of module independence is reflected in that the module completes an independent function, and the connection with other modules should be as simple as possible, with relative independence of each module.

1. Module size should be appropriate

The module size cannot be too large or too small. If the module function is too strong, readability will be poor; if the module function is too weak, there will be many interfaces. Developers need to accumulate experience through more program design.

1. Pay attention to hierarchy when decomposing modules

When performing multi-level task decomposition, attention should be paid to abstracting the problem. In the early stages of decomposition, only large modules can be considered, and in the middle stage, gradually refine and decompose into smaller modules for design.

1. Do not expose global variables

Global variables used internally in the module, when needing external modification or access, should be provided externally through encapsulating into API functions, and relevant restrictions can be implemented within the functions to prevent external direct operation of the global variables inside the module, causing module operation exceptions, thus the global variables inside the module can be defined as static global variables.

4. How to Understand

Usually, a module is a combination of a .c file and a .h file, with the header file (.h) declaring the interface of that module.

1. The .c file of the module implements specific functions, while the .h file provides the interface functions of that functional module, etc.

2. A large module may also contain multiple small modules, meaning that multiple .c and .h files exist within the module, each serving different purposes.

3. Each .c file must have a corresponding .h file, but a .h file does not necessarily need a corresponding .c file.

For example, to implement an OLED driver module, there may be the following files:

• oled.c and oled.h

Implement specific functions, such as clearing the screen, drawing, character display, etc.; the .h file provides API interface functions.

• oledio.c and oledio.h

Implement low-level interface initialization and communication (IIC or SPI), providing driver interfaces for the oled.c file.

• oledconf.c and oledconf.h

Driver configuration, such as font size, resolution, and other configuration information.

• fontxxx.h and bmpxxx.h

Used to store font and BMP graphic dot matrix data.

———— END ————

Follow the public account Reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.

Click “Read the Original” to see more shares.