Difference Between Cohesion And Coupling Explained (With Examples)

Cohesion and coupling are two important concepts in the field of software engineering. They are used to describe the relationships and interactions between different components or modules within a software system.

Cohesion refers to the degree to which the elements within a module or component are related and function together as a unified whole. On the other hand, coupling refers to the degree of interdependence between different modules or components within a software system.

Example: Consider a software system that manages a library. The module responsible for handling book borrowing and returning operations should have high cohesion, as all the functions and data related to these operations are grouped. However, it should have low coupling with other modules such as the module responsible for managing book inventory, as changes in one module should not heavily impact the other.

Software developers need to keep track of the coupling and cohesion between the modules because, without records, a lot of time would be spent checking and rechecking the changes in the system. They also need to understand the degree and type of cohesion and couple required to better design the system. Thus, it becomes imperative to understand the underlying difference between cohesion and coupling.

Difference between Cohesion and Coupling

The major difference between cohesion and coupling is that cohesion deals with the interconnection between the elements of the same module. But, coupling deals with the interdependence between software modules.

The table shown below better explains the difference between cohesion and coupling:

Criteria	Cohesion	Coupling
Definition	Cohesion refers to how closely the responsibilities of a module or class are related to each other. It measures how focused and unified a module or class is in terms of its functionality.	Coupling refers to how dependent one module or class is on another module or class. It measures the level of interdependence between modules or classes.
Type of Approach	It’s an intra-module approach	It’s an inter-module approach
High Cohesion/ High Coupling	High cohesion indicates that a module or class has a single, well-defined responsibility and performs a specific set of related tasks. It promotes code reusability, maintainability, and testability.	High coupling indicates that a module or class is tightly coupled to other modules or classes, making it difficult to modify or reuse without affecting other parts of the system. It can lead to code duplication and decrease maintainability.
Low Cohesion/ Low Coupling	Low cohesion refers to a lack of focus and unity in a module or class. It can negatively impact the maintainability and understandability of a module or class, as it becomes harder to identify and modify specific parts of the code.	Low coupling indicates a high level of interdependence between modules or classes. It can lead to a higher degree of reusability and modularity, as changes in one module or class are less likely to have a ripple effect on others.
Types	Types of cohesion include functional cohesion, sequential cohesion, communicational cohesion, procedural cohesion, and temporal cohesion.	Types of coupling include content coupling, common coupling, control coupling, stamp coupling, and data coupling.
Purpose	Cohesion is desirable as it helps in creating modular, maintainable, and reusable code.	Coupling should be minimized as it helps in creating flexible, scalable, and loosely coupled systems.

Now that we’ve understood the difference between cohesion and coupling, let’s understand both concepts in detail:

What is Cohesion in Software Engineering?

Cohesion is defined as the degree to which the elements of a particular module are functionally related. In other words, it measures how well the responsibilities and tasks within a module are aligned and focused. High cohesion is desirable as it leads to better maintainability, reusability, and understandability of the code. For example, a module that only handles file input/output operations would have high cohesion.

Since cohesion is used to measure the functional strength of a module systems having high cohesion will have strongly connected elements such as instructions, groups of instructions, the definition of data, etc. This helps in improving the focus on a given task and thus, high cohesion is preferred.

Common types of cohesion in software engineering include:

Functional Cohesion: This type of cohesion occurs when the elements within a module perform similar functions. In this type of cohesion, the elements inside a module work together to achieve one common goal. The elements work in coordination with the main aim of staying focused on the task assigned. Thus, they only perform the activities necessary for the assigned tasks. For example, a module that calculates the area and perimeter of a rectangle would exhibit functional cohesion.
Sequential Cohesion: Maintaining a sequence of activities makes our task much easier, right? That’s exactly what sequential cohesion does. Sequential cohesion is present when the elements within a module are arranged in a specific order, and the output of one element serves as the input for the next. This helps in easy maintenance and provides good coupling due to a well-defined sequence. An example of sequential cohesion can be seen in a module that reads data from a file, processes it, and then writes the results to another file.
Communicational Cohesion: Communicational cohesion exists when the elements within a module are related through a common data structure or shared data. For instance, a module that retrieves customer information from a database and displays it on a webpage would demonstrate communicational cohesion.
Procedural Cohesion: Procedural cohesion occurs when the elements within a module are grouped based on the steps required to achieve a specific task. An example of procedural cohesion can be observed in a module that handles user authentication, which includes steps such as validating credentials, generating access tokens, and updating user activity logs.
Temporal Cohesion: Temporal cohesion is present when the elements within a module are related to a specific time frame or event. For example, a module that sends reminder notifications to users based on their scheduled appointments would exhibit temporal cohesion.
Logical Cohesion: Logical cohesion occurs when the elements within a module are grouped based on a common logical relationship. An example of logical cohesion can be seen in a module that performs various mathematical operations, such as addition, subtraction, multiplication, and division.

By understanding and applying these types of cohesion, software engineers can design modules that are more modular, maintainable, and easier to understand and modify.

What is Coupling in Software Engineering?

Coupling is defined as the degree to which the two modules are dependent on each other. It measures the strength of relationships between modules. Loosely coupled systems have modules that hardly depend on other modules and can focus better on their assigned tasks.

Low coupling is desirable as it leads to better modularity, flexibility, and testability of the code. For example, if a change in one module requires making modifications in multiple other modules, it indicates high coupling.

There are several common types of coupling in software engineering. Each type represents a different level of dependency between modules or components in a system. Here are some examples:

Content Coupling: This type of coupling occurs when one module directly accesses or modifies the content of another module. In this type of coupling, the interacting modules share code. Here one module depends on the implementation of the other module. For example, if module A directly reads or modifies a data structure defined in module B, it is considered content coupling.
Common Coupling: Common coupling happens when multiple modules depend on a shared global variable or data. For instance, if multiple modules in a system access a global configuration file, they are tightly coupled through the common data.
Control Coupling: Control coupling occurs when one module controls the behavior of another module by passing control information. An example of this is when module A calls a function in module B and passes a control flag or parameter to determine the execution flow.
Stamp Coupling: Stamp coupling refers to a situation where modules communicate by passing a large data structure, but only a small portion of that data is used. For example, if module A passes a complex object to module B, but module B only needs a few fields from that object, it is considered stamp coupling.
Data Coupling: Data coupling is a desirable level of coupling where modules communicate by passing only the necessary data between them. The data shared can be of integer or float data types. In this case, modules are independent of each other's internal structure. For instance, if module A sends specific data to module B without any knowledge of how module B processes it, it demonstrates data coupling.
External Coupling: External coupling is a type of coupling where modules depend on external entities or systems outside of the software system. This type of coupling occurs when a module relies on external libraries, APIs, databases, or other software components to perform its functions. For example, let's say we have a module that needs to perform complex mathematical calculations. Instead of implementing the mathematical algorithms from scratch, the module depends on an external math library that provides pre-built functions for various mathematical operations.

It's important to note that the ideal level of coupling depends on the specific requirements and design goals of a software system. While some level of coupling is necessary for modules to work together, excessive coupling can make the system difficult.

Apart from the common types listed above, there is also no direct coupling. Here’s what that entails:

No direct coupling

No direct coupling refers to a design principle in software engineering where two components or modules are not directly dependent on each other. Instead, they interact through an intermediary or an interface. This approach promotes loose coupling and enhances the flexibility and maintainability of the system.

For example, let's consider a car and its engine. In a tightly coupled design, the car and the engine would be directly connected, meaning any change in the engine would directly impact the car's performance. However, in a loosely coupled design, the car and the engine would interact through an interface, such as the transmission system. This allows for easier upgrades or replacements of the engine without affecting the overall functionality of the car.

By avoiding direct coupling, software systems can be more modular, scalable, and adaptable. Changes or updates in one component can be made independently, minimizing the risk of unintended consequences or disruptions in the system as a whole.

Though there is a significant difference between cohesion and coupling, both are extremely useful in the design of the software. While low coupling can assure less dependency on other modules, high cohesion improves the functional strength of a module. Thus, when developers understand this key difference between cohesion and coupling, the design in software engineering can be improved.

Frequently Asked Questions (FAQs)

1. What is the difference between cohesion and coupling in software development?

Cohesion refers to the degree to which the elements within a module or component of a software system are related and work together to achieve a common purpose. On the other hand, coupling refers to the degree of interdependence between different modules or components in a software system.

2. How does cohesion affect the overall quality of a software system?

High cohesion in a software system indicates that the elements within a module are closely related and focused on a specific task, which leads to better maintainability, reusability, and understanding of the code. It improves the overall quality of the software system by making it easier to modify and test.

3. What are the consequences of high coupling in software design?

High coupling in software design can lead to several consequences. It makes the system more difficult to understand, modify, and maintain. It increases the risk of unintended side effects when making changes to one module, as it may impact other tightly coupled modules. It also reduces the reusability and flexibility of the code.

4. Can you provide examples of high cohesion and low coupling in software development?

An example of high cohesion is a module that solely focuses on handling user authentication and has functions related to login, logout, and password reset. An example of low coupling is when two modules communicate through well-defined interfaces, where changes in one module do not require modifications in the other module.

5. How can we measure the level of cohesion and coupling in a software system?

The level of cohesion and coupling in a software system can be measured using various metrics. Cohesion can be measured using metrics such as LCOM (Lack of Cohesion of Methods) or CAM (Cohesion Among Methods). Coupling can be measured using metrics such as CBO (Coupling Between Objects) or RFC (Response for a Class).

You might also be interested in reading:

Shreeya Thakur

Sr. Associate Content Writer at Unstop

I am a biotechnologist-turned-content writer and try to add an element of science in my writings wherever possible. Apart from writing, I like to cook, read and travel.