Software design-"High Cohesion and low coupling"

 

Coupling Degree
1. What is coupling degree?
In software design, coupling and cohesion are commonly used as the criteria for measuring the degree of module independence. One criterion for block division is high cohesion and low coupling. Coupling is a measure of the degree of association between modules. The coupling strength depends on the complexity of the interface between modules, the method of calling the module, and the amount of data transmitted through the interface. The Coupling Degree between modules refers to the dependency between modules, including the control relationship, call relationship, and data transmission relationship. The more inter-module connections, the stronger the coupling, and the poorer the independence. Reducing the Coupling Degree between modules can reduce the impact between modules, prevent the Water Wave Effect Caused by modifications to a module, and ensure smooth system design.
Cohesion is closely related to coupling. modules with strong coupling relationships with other modules often have a weak cohesion. Strong cohesion often means weak coupling.
Coupling is the degree of association, perception, and dependency between a module (class) and other modules (classes). It is an indicator to measure code independence and is also a software engineering design.

And a standard for coding quality evaluation. Coupling strength depends on the following factors:

(1) calls from one module to another;

(2) Data Volume transmitted by one module to another module;

(3) The amount of control a module has applied to another module;

(4) Complexity of interfaces between modules.
Coupling can be divided into the following types in the order of strength to weakness:
A) non-direct coupling: there is no direct relationship between the two modules. The connection is completely achieved through the control and call of the main module.

B) Data coupling: one module accesses the other and exchanges input and output information through simple data parameters. The simple data parameters here are different from control parameters, public data structures, or external variables.

C) Tag coupling: if a group of modules pass the record information through the parameter table, it means tag coupling. This record is a sub-structure of a data structure, not a simple variable.

D) control coupling: one module selects the function of another module by passing control information such as switch, sign, and name.

E) External coupling: A group of modules access the same global simple variable instead of the same global data structure, and do not pass the information of this global variable through parameters.

F) Public coupling: A group of modules access the same public number.

Data environment. The public data environment can be a global data structure, a shared communication area, and a public coverage area of the memory.

G) content coupling: one module directly modifies the data of another module, or directly transfers the data to another module.

Cohesion refers to the closeness between various internal elements. The module cohesion types can be divided into seven types.

The highest order is: Accidental cohesion, logical cohesion, instantaneous cohesion, process cohesion, communication cohesion, sequential cohesion, and functional cohesion.

Ii. Why low coupling?

After learning about coupling and coupling classification, I think you have some knowledge about why to reduce coupling, and most developers have probably tried the difficulties of high coupling.

Header. The reason is very simple. When the coupling degree is very high, modifying a part of the code during maintenance will be related to many places. If the coupling relationship is not clarified during the modification, the consequences will be

It may be disastrous, especially for projects with many changes in requirements and collaborative development and maintenance by many people, modifying a place will cause a module error that is already running stably. In severe cases

This leads to a vicious circle, the problem can never be solved, and the development and testing are all exhausting various problems. In the end, the project is postponed, the user satisfaction is reduced, and the cost is increased.

And the developer's influence is very bad, and various risks are self-evident.
To prevent these problems, one of the important measures is to reduce the code coupling. However, there cannot be absolute zero coupling. For example, for J2EE-based programming, it must be consistent with JDK.

Coupling, and high coupling is not useless. If you don't want to modify a function in the early stage of the design, even if the high coupling is not necessary. However, you cannot

Before designing code that does not need to be modified, it is required to take low coupling as the standard. So how can we minimize coupling? The following describes several methods to reduce coupling.

Iii. methods to reduce Coupling
1. less use of class inheritance, and more use of interfaces to hide implementation details. In addition to supporting polymorphism, the Java object-oriented programming interface also aims to hide implementation details.
2. The functional score of a module is as single as possible. The principle is also very simple. There are few opportunities for a single module to be called by other modules. (In fact, this is a saying that high cohesion is low.

Coupling usually occurs at the same time. In order to limit the length of space, we will discuss it later ).
3. Follow a definition and only appear in one place.
4. Use less global variables.
5. Class Attribute and method declarations use less public and more private keywords,
6. Use multiple design modes. For example, using the MVC design mode can reduce the coupling between the interface and business logic.
7. Try not to write programs using hard encoding, and avoid using SQL statements to operate databases directly.
8. In the end, of course, avoid directly operating or calling other modules or classes (content coupling). If coupling exists between modules, try to use data coupling in principle and use less control coupling,

Restrict the scope of public coupling to avoid content coupling.

Cohesion: the length of the internal aggregation and association. High cohesion refers to the high clustering and association.
High Cohesion: the relationship between classes depends on the relationship between classes. High indicates that the relationship between classes should be simple, clear, and not strongly related. Otherwise, problems may occur during running. The running of one class affects other classes. High Cohesion is recommended in the module design because of its robustness, reliability, reusability, and readability.

This is a concept in software engineering. It is a standard for judging the quality of the design, mainly for OO design, mainly to check whether the cohesion of the class is high and the coupling degree is low.

"High Cohesion and low coupling", you must first know that a software is composed of multiple subprograms,
A program consists of multiple modules (methods!
"High Cohesion and low coupling" mainly describes the idea of separation of duties for various classes in the object-oriented system.
Each class completes a specific independent function, which is high cohesion. Coupling is the mutual call relationship between classes. If the coupling is strong and there are many calls to each other, it will take a long time, which is not conducive to maintenance and expansion.
The setting between classes should be low coupling, but each class should be highly cohesive. coupling is the scale of mutual dependency between classes. if each object references all other objects, there is a high coupling, which is not required because there is too much information flowing between the two objects. low coupling is required: it means that objects work more independently of each other. low coupling minimizes the modification of a class and causes the "chain reaction" of other classes to be modified ". cohesion is the scale of the Connection Strength between variables and methods in a class. high Cohesion is worth it, because it means the class can better execute a job. low cohesion is not good because it indicates that there is little correlation between elements in the class. components are associated with each other. each method should also be highly cohesive. most methods only execute one function. do not add extra commands to the method. This will cause the method to execute more functions.

 
To put it bluntly, this idea is not limited to the relationship between classes. Both modules and subsystems must comply with this principle to design a system with high scalability.