Coupling and cohesion in Software Engineering - Full Explanation

Introduction

When building software, parts need to work together smoothly without being too dependent or too scattered. Finding the right balance helps make programs easier to understand, change, and fix.

Explanation

Coupling

Coupling describes how much one part of a program relies on another. If parts are tightly connected, a change in one can cause problems in others. Loose coupling means parts work more independently, making the system easier to maintain.

Loose coupling means parts depend less on each other, improving flexibility.

Types of Coupling

Coupling ranges from tight to loose. Tight coupling happens when parts share many details or data directly. Loose coupling happens when parts communicate through simple, clear interfaces without knowing internal details.

Using simple interfaces reduces coupling and improves system design.

Cohesion

Cohesion measures how closely related the tasks within a single part are. High cohesion means a part does one clear job well. Low cohesion means a part tries to do many unrelated things, making it harder to understand and maintain.

High cohesion means a part focuses on a single task, making it clearer and easier to manage.

Types of Cohesion

Cohesion can be functional, where all tasks contribute to one function, or it can be weaker, like when tasks are only loosely related. Strong cohesion helps keep code organized and easier to test.

Functional cohesion leads to better organized and more reliable code.

Real World Analogy

Imagine a team working on a project. If team members depend too much on each other's detailed work, delays happen when one person changes their part. But if each member focuses on their own clear task and communicates simply, the project flows smoothly.

Coupling → Team members depending heavily on each other's detailed work

Loose Coupling → Team members working independently and sharing only necessary information

Cohesion → Each team member focusing on a single clear task

Functional Cohesion → A team member whose tasks all contribute directly to one goal

Diagram

Diagram

┌─────────────┐       ┌─────────────┐
│   Module A  │──────▶│   Module B  │
└─────────────┘       └─────────────┘
      │                     │
      │ Loose Coupling       │ Tight Coupling
      ▼                     ▼
┌─────────────┐       ┌─────────────┐
│  Single Job │       │ Multiple Jobs│
│ (High Coh.) │       │ (Low Coh.)  │
└─────────────┘       └─────────────┘

This diagram shows modules with different coupling and cohesion levels: loose vs tight coupling and high vs low cohesion.

Key Facts

Coupling → The degree to which one module depends on another.

Loose Coupling → Modules interact through simple interfaces with minimal knowledge of each other.

Tight Coupling → Modules are highly dependent on each other's internal details.

Cohesion → How closely related the responsibilities of a single module are.

High Cohesion → A module performs a single, well-defined task.

Low Cohesion → A module handles unrelated tasks, making it complex and hard to maintain.

Common Confusions

Believing tight coupling is always bad.

Believing tight coupling is always bad. Tight coupling can be acceptable in small, simple programs but causes problems as systems grow and change.

Thinking cohesion and coupling are the same.

Thinking cohesion and coupling are the same. Cohesion is about how focused a single part is, while coupling is about how much parts depend on each other.

Summary

Loose coupling means parts of a program depend less on each other, making changes easier.

High cohesion means each part focuses on one clear task, improving clarity and maintenance.

Good software design balances low coupling with high cohesion for better flexibility and organization.

Practice

1. What does low coupling in software design mean?

easy

A. Modules have few dependencies on each other

B. Modules perform many unrelated tasks

C. Modules are tightly connected and dependent

D. Modules share all their data freely

Solution

1. Step 1: Understand coupling concept

   Coupling measures how much modules depend on each other.

2. Step 2: Interpret low coupling

   Low coupling means modules have few dependencies, making them independent.

3. Final Answer:

   Modules have few dependencies on each other -> Option A

4. Quick Check:

   Low coupling = few dependencies [OK]

Hint: Low coupling means less dependency between modules [OK]

Common Mistakes:

• Confusing low coupling with high dependency
• Thinking low coupling means modules do many tasks
• Mixing coupling with cohesion concepts

2. Which of the following best describes high cohesion in a module?

easy

A. The module depends heavily on other modules

B. The module performs many unrelated tasks

C. The module focuses on a single, well-defined task

D. The module shares data with all other modules

Solution

1. Step 1: Understand cohesion concept

   Cohesion measures how focused a module is on a single task.

2. Step 2: Interpret high cohesion

   High cohesion means the module focuses on one clear, well-defined task.

3. Final Answer:

   The module focuses on a single, well-defined task -> Option C

4. Quick Check:

   High cohesion = single focused task [OK]

Hint: High cohesion means one clear task per module [OK]

Common Mistakes:

• Thinking high cohesion means many unrelated tasks
• Confusing cohesion with coupling
• Assuming high cohesion means high dependency

3. Consider two modules: Module A calls Module B frequently and shares many variables. Module C performs one clear task independently. Which statement is true?

medium

A. Module A has low coupling and high cohesion

B. Module A has high coupling and Module C has high cohesion

C. Module B has high cohesion and low coupling

D. Module C has high coupling and Module A has low cohesion

Solution

1. Step 1: Analyze Module A and B relationship

   Module A calls Module B frequently and shares many variables, indicating high coupling.

2. Step 2: Analyze Module C's task focus

   Module C performs one clear task independently, indicating high cohesion.

3. Final Answer:

   Module A has high coupling and Module C has high cohesion -> Option B

4. Quick Check:

   High coupling = many dependencies; High cohesion = focused task [OK]

Hint: Frequent calls = high coupling; single task = high cohesion [OK]

Common Mistakes:

• Mixing which module has high coupling
• Confusing cohesion with coupling
• Assuming independence means low cohesion

4. A software module is designed to handle user input, process data, and generate reports all in one. What is the main problem here?

medium

A. The module has low cohesion

B. The module has low coupling

C. The module is highly focused

D. The module is loosely connected

Solution

1. Step 1: Identify tasks in the module

   The module handles user input, processes data, and generates reports, which are different tasks.

2. Step 2: Assess cohesion level

   Because it does many unrelated tasks, the module has low cohesion.

3. Final Answer:

   The module has low cohesion -> Option A

4. Quick Check:

   Multiple unrelated tasks = low cohesion [OK]

Hint: Many tasks in one module means low cohesion [OK]

Common Mistakes:

• Confusing low cohesion with low coupling
• Thinking multiple tasks mean high cohesion
• Ignoring the definition of cohesion

5. You have a large software system with modules that share many variables and perform multiple unrelated tasks. To improve design, which approach should you take?

hard

A. Increase coupling and decrease cohesion

B. Increase both coupling and cohesion

C. Keep coupling and cohesion as they are

D. Decrease coupling and increase cohesion

Solution

1. Step 1: Identify current design issues

   Modules share many variables (high coupling) and perform unrelated tasks (low cohesion).

2. Step 2: Apply good design principles

   Good design aims for low coupling (less dependency) and high cohesion (focused tasks).

3. Final Answer:

   Decrease coupling and increase cohesion -> Option D

4. Quick Check:

   Good design = low coupling + high cohesion [OK]

Hint: Aim for less dependency and focused tasks [OK]

Common Mistakes:

• Thinking increasing coupling improves design
• Confusing cohesion with coupling
• Ignoring the benefits of modular design