Software Engineering Principle — Coupling & Cohesion

Hi engineers and peers, In this article, I’ll be discussing one of the core software engineering principles, that every software engineer should know or at least be aware of it. As we engineers are supposed to grow in our careers, we have to upgrade our skills whether it’s practical or theoretical.

So from this article, I am starting to share some software engineering principles & design patterns for writing better and cleaner code with best practices. This is the first one of this series, in which I’ll be discussing the importance of coupling & cohesion in software. But before moving into the main topic, we should know what is modularization so we can grasp the concept of coupling easily.

Modularization: is a process of breaking software into multiple small modules, where each module works independently. The main advantage of modularization is that it is easy to understand the software, it becomes reusable and can be tested easily.

What is Coupling in Software Engineering?

Coupling: in software engineering is the inter-dependency or degree of relationship between multiple modules/packages/components. Coupling is also called Inter-Module Binding.

Multiple modules/packages/components that are highly coupled are strongly dependent on each other.

Multiple modules/packages/components that are loosely coupled are not or somehow dependent on each other.

Good software is always loosely coupled so it is considered as best practice to make your modules/packages/components loosely coupled or interdependent so that they can be tested and managed to maintain easily. The more number of calls between the modules increases the more it’ll prone to errors. For low-coupled classes, changing something major in one class should not affect the other. High coupling would make it difficult to change and maintain your code

Below is the image for visualization of the coupling

Types of Coupling

1. Data Coupling: When modules share primitive data between them.

2. Stamp Coupling: When modules share composite or structural data between them It must be a non-global data structure. for example, Passing object or structure variable in react components.

3. Control Coupling: When data from one module is used to direct the structure of instruction execution in another.

4. External Coupling: When two modules share externally imposed data type that is external to the software like communication protocols, and device interfaces.

5. Common Coupling: When two modules share the same global data & dependent on them, like state management in JavaScript frameworks.

6. Content Coupling: When two modules share code and can modify the data of another module, this is the worst coupling and should be avoided.

So now you get the idea of Coupling in software engineering, there is another concept that is used with coupling known as cohesion.

What is Cohesion in Software Engineering?

Cohesion refers to what the module can do, internally. It is also called Intra-Module binding as it measures the strength of the relationship of functionalities inside a module/package/component. Cohesion should always be high means that a module/package/component is focused on what it should be doing, i.e. only methods relating to the intention of the class.

Example of low cohesion:

-------------------
|Add To Cart module|
-------------------
| login()              |
| selectProduct()      |
| getShippingDetails() |
| PrintReceipt()       |
-------------------

Example of high cohesion

----------------------------
| Add To Cart module      |
----------------------------
| selectProduct()         |
| getShippingDetails()    |
| calculatePrice()  |     |
----------------------------

In the above example, you see that the login function is not relatable to the cart module, which is low cohesion which is considered bad in software engineering.

Types of Coupling

1. Functional Cohesion: The execution of the task related to the problem is the only concern of all the elements inside the module.

2. Sequential Cohesion: The output of an element is the input of another element in a module i.e., data flow between the parts.

3. Communicational Cohesion: Multiple elements in a module operate on the same input data and produce the same output data.

4. Procedural Cohesion: The activities in the module are related by sequence, otherwise they are not related.

5. Coincidental Cohesion: The activities with meaningless relationships with one another are contributed by the elements in the module.

So always keep that in mind that :

Good Software has always low coupling with high cohesion