You have learned what modularization is and why it is important, but now you learn the most important principles that you need to keep in mind when defining how to modularize. Splitting the application into smaller pieces is essential in the path to modernization, but sometimes the difficult part is knowing what to include in each piece. This section addresses this point.
Keep in mind the guidelines that are described in this section when you design a modular application.
Single responsibility
This principle states that every module of an application must have one responsibility. A responsibility can be understood as a reason to change. For example, consider a module that retrieves data from a table and also generates a report that is based on the data. If a change that is related to the data retrieval must be made, the entire module must change. But if a change must be done to the report, the same module must change. Therefore, the module
has two unrelated reasons to change. The correct way is to create two modules, one focused on retrieving data and other focused on generating the report.
When a module has more than one responsibility, it is easier to cause collateral damage: You are changing the report, but the data retrieval function is also affected.
High cohesion
Cohesion is the degree in which elements of a module belong together. It is the functional relatedness of the elements within a module. You can detect low cohesion when a module has more than one responsibility. Also, low cohesion can be seen when common responsibilities are separated in different, unrelated modules.
You should design components with cohesion, which makes them more robust and easier to reuse. All that you have to do is put related functions in the same module and make sure that future changes take this function into consideration.
Loose coupling
Coupling can be defined as the degree to which each module relies on other modules. It is a measure of the strength of association that is established by a connection from one module to another. Tight coupling makes a program harder to understand, change, or correct by itself. A change in one module generates many changes in unrelated modules. It is like domino
pieces falling in sequence.
Achieving a design with no coupling is hard and not practical, but you must try to focus on designing with low coupling in mind. Loose coupling can be achieved by creating high cohesion modules that communicate with others through a defined interface, hiding its
internal implementation. Modules must hide their global variables, data format, and any other implementation details from other modules. Modules are called and the function within the module is affected even though only data passed in the defined interface.
Packing together only related modules
When you package your modules (service programs in the ILE context), remember to pack together only related modules. This action can be thought as the principle of high cohesion, but at the package level. Why is it important to design packages with this approach? If you pack unrelated modules together, you generate many dependencies to the package from
different applications.
A change of a module requires modifying the whole package, increasing the risk of damaging other applications.
Correct naming convention
Naming conventions must be defined in a way that helps the programmer understand the modular approach. You should define a self-documented naming convention that helps quickly identify the single function of a module.
This convention helps others to maintain the order and style of the whole application. Good naming conventions also make tools, such as UML diagrams, more useful.