Coupling refers to the degree to which one module is dependent on another module. Cohesion refers to the degree to which the elements of a module belong together. In general, it is considered good software design practice to minimize coupling and maximize cohesion. This means that modules should be designed so that they are as independent of each other as possible, and so that the elements within each module belong together as much as possible.
What is Coupling?
In software engineering, coupling is the degree of interdependence between software modules; that is, the strength of the relationships between them. Coupling is usually contrasted with cohesion. High coupling occurs when a group of modules are highly interconnected; low coupling occurs when there are few connections between modules.
Coupling can be structural or behavioral. Structural coupling is determined by the structure of the code, and includes dependencies such as inheritance, control flow, and data flow. Behavioral coupling is determined by the way in which the modules interact with each other, and includes dependencies such as function calls and shared data structures.
Coupling can be either positive or negative. Positive coupling occurs when two modules cooperate in order to achieve a common goal; negative coupling occurs when one module hinders or interferes with the functioning of another module.
In general, high coupling is considered to be a bad thing, because it makes software harder to understand and maintain. However, there are some situations where high coupling may be desirable – for example, when two modules need to share a lot of data or functionality in order to achieve a common goal.
What is Cohesion?
Cohesion is the degree to which a module is self-contained.
In general, high cohesion is desirable because it indicates that a module is focused on a single task and has all the resources it needs to complete that task. Low cohesion, on the other hand, indicates that a module is trying to do too many things or that it is not self-contained (it relies on other modules to provide some of the resources it needs).
Examples of Coupling
Imagine you have a system with three modules: A, B, and C. Module A contains information about customers, module B contains information about orders, and module C contains information about products. If there is high coupling between these modules, then a change in customer information (module A) is likely to cause changes in order information (module B) and product information (module C). On the other hand, if there is low coupling between these modules, then a change in customer information (module A) is unlikely to cause changes in order information (module B) and product information (module C).
When to Use Coupling and Cohesion
One important factor is the level of abstraction of the software. If the software is highly abstracted, then it is likely that coupling will be more important than cohesion. Another important factor is the amount of time that the software will be used. If the software will be used for a short period of time, then cohesion may be more important than coupling. Finally, the size of the team working on the software project may also influence the decision of whether to use coupling or cohesion. If the team is small, then cohesion may be more important than coupling.
How to Improve Coupling and Cohesion
There are a few different ways to improve coupling and cohesion in a software design:
-Refactor code regularly to reduce dependencies between modules.
-Keep modules small and focused on a single task.
-Implement strong abstraction layers to minimize the impact of changes in one module on other modules.
-Design for loose coupling by using techniques such as inversion of control and dependency injection.
Photo by Markus Spiske on Unsplash
