In software engineering, coupling refers to the degree of interdependence between software modules; the different types, ranked from highest (worst) to lowest (best), are content, common, control, stamp, data, and no coupling.
Here's a breakdown of each type:
Types of Coupling
| Type of Coupling | Description | Characteristics | Example | Consequences |
|---|---|---|---|---|
| Content Coupling | One module directly modifies or depends on the internal workings of another module. This is the worst type. | - A module directly references or modifies the data or code within another module. - Modules are highly intertwined. - Changes to one module require changes in the other. | Module A directly modifies a variable within Module B. Module A jumps to a specific label or address within Module B. | Extremely difficult to maintain and debug. Changes in one module almost certainly break the other. Reusability is virtually impossible. |
| Common Coupling (or Global Coupling) | Modules share the same global data. | - Modules share access to the same global data structures or variables. - Changes to the global data affect all modules that use it. - Hard to trace data modifications and dependencies. | Multiple modules access and modify the same global configuration file. Multiple modules rely on the same global variable for system status. | Increases complexity and reduces modularity. Difficult to understand how changes in one module can impact other modules. Can lead to unexpected side effects. Testing and debugging become significantly harder. |
| Control Coupling | One module controls the logic flow of another module by passing control information. | - One module passes flags or control signals to another module, dictating its behavior. - The controlled module's functionality depends on the control signal. - High risk that changes to the control module require changes to the controlled module. | Module A passes a "mode" flag to Module B, which then executes different sections of code based on that flag. | Reduces the independence of modules. Changes to the control module can force changes in the controlled module. Reduces reusability. |
| Stamp Coupling (or Data-Structured Coupling) | Modules pass complex data structures, but the receiving module only uses a portion of the data. | - Modules pass entire data structures (e.g., records, classes) to each other, even if the receiving module only needs a small part. - The receiving module has to be aware of the structure of the data, even if it doesn't use all of it. | Module A passes an entire customer object to Module B, even though Module B only needs the customer's ID. | Can lead to unnecessary dependencies and reduced modularity. If the structure of the passed data changes, the receiving module might need to be updated even if it only uses a small part of the data. |
| Data Coupling | Modules pass only the necessary data to each other. | - Modules communicate through parameters. - Only necessary data is passed. - Modules are independent and have limited knowledge of each other's internal workings. | Module A passes a customer ID and order amount to Module B to process an order. | Promotes modularity and reusability. Easier to understand and maintain. Least problematic type of coupling. |
| No Coupling | Modules are completely independent. | - Modules do not depend on each other at all. - Modules can be developed, tested, and modified independently. - Ideal, but rarely completely achievable in practice. | Two separate microservices that do not interact directly. | Simplifies development, testing, and maintenance. Maximizes reusability and flexibility. |
In general, the goal is to minimize coupling and maximize cohesion (the degree to which the elements inside a module belong together). Lower coupling makes the system easier to understand, maintain, and reuse.
