An overview of the

High cohesion and low coupling is a concept in software engineering. It is a standard to judge the quality of software design. It is mainly used in object-oriented design of programs, and mainly depends on whether the cohesion of classes is high and whether the coupling degree is low. The purpose is to enhance the reusability and portability of program modules. In general, the more cohesive the modules in the program structure, the lower the degree of coupling between modules. Cohesion measures the relationships within a module from a functional perspective. A good cohesive module should do exactly one thing. It describes the functional relationships within the module. Coupling is a measure of the interconnections between modules in a software structure. The strength of coupling depends on the complexity of the module’s indirect interface, the point of entry or access to a module, and the data passing through the interface.

concept

Coupling: also known as interblock connection. A measure of the degree to which modules in a software system structure are closely related to each other. The more closely connected modules are, the more coupled they become and the less independent they become. The level of coupling between modules depends on the complexity of the module’s indirect interface, the way of invocation and the information passed.

Cohesiveness: also known as intra-block connection. Refers to the measure of the functional strength of a module, that is, the measure of how closely each element within a module is combined with each other. The more closely the elements (between names, between segments) in a module are related, the more cohesive it will be.

High cohesion means that a software module is composed of closely related code that is responsible for only one task, which is often referred to as the principle of single responsibility.

Coupling: a measure of the degree of interconnection between different modules in a software architecture.

Low coupling is loosely understood as a complete system, module to module, as stand-alone as possible. In other words, let each module, as much as possible, perform a specific subfunction independently. Interfaces between modules should be as few and simple as possible. If the relationship between two modules is complex, it is best to consider further module division first. This facilitates modification and composition.

extension

Coupling can be divided into the following types, and the degree of coupling between them in order of high to low is as follows:

1. Content coupling: When one module directly accesses the content of another module, the two modules are called content coupling. Content coupling between two modules occurs if one of the following occurs in a program: 1). One module directly accesses the internal data of another module. 2). A module is directly transferred into the interior of another module without passing through the normal entrance. 3). Two modules have a part of the code overlap (the part of the code has a certain independent function). 4). A module has multiple entrances. Content coupling can occur in assembly language. Most high-level languages have been designed to disallow content coupling. This coupling has the strongest coupling and the weakest module independence. 2. Common coupling: A set of modules that all access the same global data structure is called common coupling. Common data environments can be global data structures, shared communication areas, common coverage areas of memory, and so on. If the module only inputs data into the common data environment or only pulls data from the common data environment, this is a loose common coupling; If the module both inputs data to and pulls data from the common data environment, this is a tighter common coupling. Common coupling may cause the following problems: 1). It cannot control the access of each module to the public data, which seriously affects the reliability and adaptability of the software module. 2). The maintainability of the software deteriorates. If a module modifies public data, the related modules are affected. 3). Reduced software comprehensibility. It is not easy to know which data is shared by which modules and it is difficult to troubleshoot. In general, common coupling is used only when there is a lot of data shared between modules and it is inconvenient to pass through parameters. 3. External coupling: When a set of modules all access the same global simple variable and do not pass information about the global variable through the parameter table, this is called external coupling. 4. Control coupling: Instead of data information, control information, such as flags and switching quantities, is passed between modules. One module controls the function of the other. 5. Tag coupling: passing data structures instead of simple data between the calling module and the called module, also known as feature coupling. Instead of passing simple variables, tag-coupled modules pass data results such as data names, record names, and file names in high-level languages. These names are called tags, but they are actually passed addresses. 6. Data coupling: Only simple data item parameters are passed between the calling module and the called module. Equivalent to value passing in a high-level language. 7. Indirect coupling: a family of two modules whose connection is entirely through the control and invocation of the main module. The coupling degree is the weakest and the module independence is the strongest.

Conclusion: Coupling is an important factor affecting the complexity and design quality of software. In order to improve module independence, we should establish a system as loose as possible between modules. In design, we should adopt the following principles: If coupling must exist between modules, data coupling should be used as much as possible, control coupling should be used less, and common coupling should be used with caution or control, and the scope of common coupling should be limited, and content coupling should be avoided as much as possible.

There are the following types of cohesion, and the degree of cohesion between them is listed from weak to strong as follows:

1. Accidental cohesion: The processing elements in a module have no connection to each other, but are only haptically aggregated. This module, also known as coincidence cohesion, is the least cohesive. 2. Logical cohesion: This module combines several related functions together, and each time it is called, the parameters passed to the module determine which function the module should perform. 3. Time cohesion: The module formed by combining the actions that need to be executed simultaneously is called time cohesion module. 4. Procedural cohesion: A combination of components or operations that allows subsequent components or operations to be called immediately after the previous component or operation, even if no data is passed between them. Simply put, if the processing elements within a module are related and must be executed in a particular order, it is called process cohesion. 5. Communication cohesion: refers to the fact that all processing elements within a module operate on the same data structure or all processing functions are associated through common data (sometimes called information cohesion). That is, each component of the module uses the same data or produces 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 performed sequentially, usually the output of the former processing element is the input of the latter. For example, when a module completes the function of evaluating industrial output value, the total output value of the former functional element is calculated, and the average output value of the latter functional element is calculated. Obviously, the two parts of the module are closely related. Sequential cohesion is relatively high, but it is not as easy to maintain as functional cohesion. 7. Functional cohesion: All components of all elements in a module exist to complete a single function, and the module can no longer be divided. That is, a module only includes all the components necessary to complete a function, which are closely related and indispensable. Functional cohesion is the strongest cohesion, and its advantage is that its function is clear. To determine whether a module is functionally cohesive, it can be seen from the module name. If the module name has only one verb and a specific target (singular noun), it is generally functional cohesion, such as: “Calculate water rate”, “calculate output value” module. 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 “black box”, and the caller of the module only needs to know what the module can do, but not how it does it.

Conclusion: When dividing modules, we should follow the principle of “one module, one function”, so as to achieve functional cohesion of modules as far as possible.

Method of reducing coupling degree

1. Use less class inheritance and more interfaces to hide implementation details. In addition to supporting polymorphism, Java object-oriented programming introduces interfaces to hide implementation details.

2. The function of modules should be as single as possible. The reason is also very simple. (In fact, this is a way of saying high cohesion, high cohesion and low coupling generally occur together).

3. Follow one definition and only one place.

4. Use global variables sparingly.

Class attributes and methods are declared using the private keyword instead of the public keyword.

6. Use design patterns, such as MVC design patterns, to reduce the coupling degree between the interface and business logic.

7, try not to “hard code” way to write programs, but also try to avoid directly using SQL statements to operate the database.

8. Finally, of course, avoid directly manipulating or calling other modules or classes (content coupling); If coupling must exist between modules, in principle, use data coupling as much as possible, control coupling less, limit the scope of common coupling, and avoid content coupling.

Enhanced cohesion method

1. The module exposes only the minimum amount of interfaces and forms the lowest dependencies.

2. As long as the external interface remains unchanged, the internal modification of the module shall not affect other modules.

3. Deleting a module should only affect other modules that have dependencies, and should not affect other irrelevant parts.

What are the benefits of a highly cohesive, low-coupling system? In fact, in the short term, there is no obvious benefit, and in the short term, it may even affect the development schedule of the system, because a highly cohesive, low-coupling system places higher demands on the developer and designer. The benefits of high cohesion and low coupling are reflected in the process of sustainable development of the system. The system with high cohesion and low coupling has better reusability, maintainability and expansibility, which can more efficiently complete the maintenance and development of the system and continuously support the development of the business without becoming an obstacle to the business development.