Software design - "high cohesion and low coupling"

Coupling degree One 、 What is coupling Software Design The degree of coupling and cohesion are usually used as the criteria to measure the degree of module independence . One of the criteria for dividing blocks is high cohesion and low coupling . Coupling degree (Coupling) Is a measure of the degree of correlation between modules . The strength of coupling depends on the complexity of the interface between modules 、 How to call the module and how much data is transferred through the interface . The coupling between modules refers to the dependency between modules , Including control relationships 、 Call relationship 、 Data transfer relationship . The more connections between modules , The stronger the coupling , At the same time, it shows that the less independent it is . Reducing the coupling degree between modules can reduce the influence between modules , To prevent the modification of a module “ Pull a body ” Water wave effect , Ensure the smooth progress of system design . Cohesion and coupling are closely related , Modules with strong coupling relationship with other modules often mean this weak cohesion , Strong cohesion often means weak coupling . Coupling is a module （ class ） And other modules （ class ） Relationship between 、 The degree of perception and dependence , Is a measure of code independence , It's also software engineering

And a standard of coding quality evaluation . The strength of the coupling depends on the following factors ：

（1） A call from one module to another ;

（2） The amount of data passed from one module to another ;

（3） How much control one module exerts on another ;

（4） The complexity of the interface between modules . Coupling can be divided into the following types from strong to weak ： a) Indirect coupling ： There is no direct relationship between the two modules , The connection between them is completely realized through the control and call of the main module 　　

b) Data coupling ： One module accesses another module , Exchange input with each other through simple data parameters 、 Output information . The simple data parameters here are different from the control parameters 、 Common data structures or external variables . 　　

c) Tag coupling ： For example, a group of modules transmit record information through the parameter table , It's tag coupling . This record is a substructure of a data structure , Not a simple variable . 　　

d) Control coupling ： A module passes a switch 、 sign 、 Name and other control information , Obvious control selects the function of another module 　　

e) External coupling ： A group of modules access the same global simple variable instead of the same global data structure , And it doesn't pass the information of the global variable through parameters 　　

f) Public coupling ： A group of modules all access the same common number

According to the environment . The public data environment can be a global data structure 、 Shared communication area 、 Public coverage area of memory, etc . 　　

g) Content coupling ： One module directly modifies the data of another module , Or directly transfer to another module 　　

Cohesion refers to the closeness of the relationship between the internal elements , The cohesive types of modules can be generally divided into 7 Kind of , According to its cohesion from low

The order of getting to the top is ： To gather by chance 、 Logical cohesion 、 Instantaneous cohesion 、 Process cohesion 、 Communication cohesion 、 Order cohesion 、 Functional cohesion .

Two 、 Why low coupling

After understanding what coupling is and the classification of coupling , I think you have a certain understanding of why to reduce the coupling , And most developers have probably tasted the pain of high coupling

head . It's simple , In the case of high coupling , Modifying one place while maintaining code can involve many places , If these coupling relationships are not clarified during modification , So the consequences

It could be catastrophic , Especially for the projects with more changes in requirements and multiple people's cooperative development and maintenance , Modifying a location will cause a module error that is already running stably , When it is serious, it will

Lead to a vicious circle , The problem can never be solved , Development and testing are all about problems , Finally, the project was delayed , Reduced user satisfaction , The cost has also increased , It's good for users

And the impact of developers is very bad , All kinds of risks are self-evident . In order to prevent these problems , One of the important means is to reduce the coupling of code . But there can be no absolute zero coupling , For example, based on J2EE Programming must be done with JDK

coupling , And high coupling is not useless , If you expect a function in the early stage of design, you basically don't need to modify it in the later stage , It doesn't matter even if the coupling is high . however , Not yet capable

Before designing code that basically doesn't need to be modified , Low coupling is also required as the standard . So how can we minimize the coupling degree ？ Here are several ways to reduce coupling .

3、 ... and 、 Methods of reducing coupling 1、 Use less class inheritance , Multiple interfaces hide implementation details . java In addition to supporting polymorphism, object-oriented programming introduces interfaces , Hiding implementation details is also one of the purposes . 2、 The functionalization of modules is as single as possible , It's also very simple , There is less chance for a single function module to be called by other modules .（ In fact, this is a saying of high cohesion , High cohesion low

Coupling usually occurs at the same time , In order to limit the space , We will discuss in a later issue ）. 3、 Follow a definition only in one place . 4、 Use less global variables . 5、 Class properties and method declarations are less public, multi-purpose private keyword , 6、 Multi use design patterns , For example, using MVC Design pattern can reduce the coupling degree between interface and business logic . 7、 As far as possible need not “ Hard encoding ” How to write a program , At the same time, try to avoid using SQL Statement operation database . 8、 Finally, of course, avoid directly operating on or calling other modules or classes （ Content coupling ）; If there must be coupling between modules , In principle, try to use data coupling , Use less control coupling ,

Limit the scope of public coupling , Avoid using content coupling .

cohesion ： So it's called thoughtfulness , Indicates internal aggregation 、 Length of Association , So high cohesion means a high degree of aggregation and correlation . High cohesion : The relationship between classes depends on , high , It means that the relationship between them should be simple , clear , Don't have a strong relationship , Otherwise , There will be problems when it runs . The operation of one class affects other classes . Because of its high cohesion, it is robust , reliability , Reusability , Readability and so on , High cohesion is recommended for module design .

This is the concept of software engineering , It's the standard to judge the design , Mainly for OO The design of the , Mainly to see if the class cohesion is high , Whether the coupling degree is low

“ High cohesion , Low coupling ”, First of all, you need to know that a software is composed of multiple subroutines , A program consists of multiple modules ( Method ) constitute ! “ High cohesion , Low coupling ” It mainly describes the object-oriented system , Each class needs the idea of separation of duties . Each class performs a specific independent function , This is high cohesion . Coupling is the calling relationship between classes , If the coupling is strong , There's a lot of interaction , Then I will pull one hair and move my whole body , Not conducive to maintenance and expansion . The settings between classes should be low coupling , But each class should be highly cohesive . Coupling is a measure of the interdependence between classes . If each object has references to all other objects , So there's high coupling , It's not up to the requirements , Because between two objects , There's potentially too much information flowing . Low coupling is desirable : It means that objects work more independently of each other . Low coupling minimizes the need to modify one class, resulting in changes to other classes as well ” chain reaction ”. Cohesion is a measure of the strength of the connection between variables and methods in a class . High cohesion is worth it , Because it means that classes can do a better job . Low cohesion is not good , Because it shows that there is little correlation between elements in a class . The modules associated with each other are satisfactory . Each method should also be highly cohesive . Most methods perform only one function . Do not add ’ additional ’ Instructions , This causes the method to execute more functions . Let's promote it , This idea is not limited to the relationship between classes . Modules and modules , This principle should also be observed between subsystems , Then we can design a system with strong ductility .

Publisher ： Full stack programmer stack length , Reprint please indicate the source ：https://javaforall.cn/113822.html Link to the original text ：https://javaforall.cn