Coupling can be divided into the following types, and the degree of coupling between them is arranged from high to low as follows:
1. Content coupling
When one module directly accesses the content of another module, the two modules are said to be content coupled .
If one of the following situations occurs in the program, it means that content coupling occurs between two modules:
1) One module directly accesses the internal data of another module.
2) A module directly enters the interior of another module without going through the normal entrance.
3) The two modules have a part of the code overlap (this part of the code has certain independent functions).
4) A module has multiple entries.
Content coupling can occur in assembly language . Most high-level languages are designed not to allow content coupling. This coupling has the strongest coupling and the weakest module independence.
2. Public coupling
A group of modules that all access the same global data structure is called public coupling . The common data environment can be a global data structure, a shared communication area, a common footprint of memory, etc. If the module only inputs data to the public data environment, or only retrieves data from the public data environment, this is a relatively loose public coupling; if the module both inputs data to the public data environment and retrieves data from the public data environment, this is a tighter coupling public coupling .
Public coupling can cause the following problems:
1) It is impossible to control the access of each module to public data, which seriously affects the reliability and adaptability of software modules.
2) Make the maintainability of the software worse. If a module modifies public data, it will affect related modules.
3) Reduced software comprehensibility. It is not easy to clearly know which data is shared by which modules, and it is difficult to troubleshoot.
In general, public coupling is only used when there is a lot of data shared between modules and passing parameters is inconvenient.
3. External coupling
When a group of modules all access the same global simple variable , and do not pass the information of the global variable through the parameter table, it is called external coupling.
4. Control coupling
What is passed between modules is not data information, but control information such as signs, switches, etc., and one module controls the function of another module.
5. Label coupling
Passing data structures rather than simple data between the calling module and the called module is also called feature coupling. What is passed between tag-coupled modules is not simple variables, but data results such as data names, record names, and file names in high-level languages. These names are tags, and what is actually passed is an address.
6. Data coupling
Only simple data item parameters are passed between the calling module and the called module. Equivalent to pass by value in high-level languages.
7. Indirect coupling
The relationship between the two modules is completely realized through the control and calling of the main module. The coupling degree is the weakest, and the module independence is the strongest.
Summary: Coupling is an important factor that affects software complexity and design quality. In order to improve the independence of modules, a system that is as loose as possible between modules should be established. In design, we should adopt the following principles: If there must be coupling between modules, it should be Use data coupling as much as possible, use less control coupling, use public coupling with caution or in a controlled manner, limit the scope of public coupling, and try to avoid content coupling.
There are the following types of cohesion, and the degree of cohesion among them is arranged from weak to strong as follows:
1. Accidental cohesion
The processing elements within a module are not connected in any way, but are brought together by accident. Such modules are also known as coincidentally cohesive and are the least cohesive.
2. Logic cohesion
This kind of module combines several related functions together, and each time it is called, the parameters sent to the module determine which function the module should complete.
3. Gathering in time
A module formed by combining actions that need to be executed simultaneously is called a temporal aggregation module.
4. Process Cohesion
The combination of components or operations is to allow calling the following components or operations immediately after invoking the previous components or operations, even if there is no data transfer between the two. Simply put, if the processing elements in a module are related and must be executed in a specific order, it is called process cohesion.
V. Communications
Refers to the fact that all processing elements within a module operate on the same data structure or that all processing functions are related through common data (sometimes called information cohesion). That is to say, each component in the module uses the same data or generates the same data structure.
6. Sequential Cohesion
Each processing element in a module is closely related to the same function, and these processing must be executed sequentially, usually the output of the former processing element is the input of the latter processing element.
For example, a module completes the function of industrial output value evaluation, the former functional element calculates the total output value, and the latter functional element calculates the average output value. Obviously, the two parts in this module are closely related.
The cohesion of sequential cohesion is relatively high, but the disadvantage is that it is not as easy to maintain as functional cohesion.
Seven, functional cohesion
All components of all elements in the module exist to complete the same function, and together complete a single function, the module can no longer be divided. That is to say, the module only includes all the components necessary to complete a certain function, and these components are closely related and indispensable.
Functional cohesion is the strongest cohesion, and its advantage is that its function is clear. Judging whether a module is functionally cohesive can generally be seen from the module name. If the module name has only one verb and a specific goal (singular noun), it is generally functionally cohesive, such as: "calculate water bill", "calculate output value" and other modules. Functional cohesion generally occurs at the lower levels of the software architecture diagram.
An important feature of a functional cohesive module is that it is a "cassette box". For the caller of the module, he only needs to know what the module can do, but not how the module does it.
Summary: When dividing modules, follow the principle of "one module, one function" to make the modules functionally cohesive as much as possible.
Reposted from: https://blog.csdn.net/caoxuecheng001/article/details/80231220