Cohesion and Coupling — Software Engineering

Measuring module quality through internal relatedness and external dependencies.

Cohesion and coupling are the two most important metrics for evaluating module quality in software design. Cohesion measures how strongly the elements within a single module are related to each other. Coupling measures how strongly different modules depend on each other. The universal design goal is high cohesion within modules and low coupling between modules. This combination produces systems where each module has a clear, focused purpose and can be modified independently—the foundation of maintainable software.

Cohesion: Internal Strength

Cohesion measures the degree to which elements within a module belong together. A highly cohesive module does one thing well—all its functions, data, and operations are related to a single, well-defined purpose. Low cohesion means a module is a grab-bag of unrelated functions thrown together by convenience rather than design.

Types of Cohesion (Worst to Best)

Coincidental Cohesion (worst): Elements are grouped arbitrarily with no meaningful relationship. A "UtilityModule" containing string formatting, date calculations, file I/O, and encryption functions has coincidental cohesion—these functions are together only because someone needed to put them somewhere.

Logical Cohesion: Elements perform similar operations but are unrelated in purpose. An "InputHandler" module that handles keyboard input, file input, network input, and sensor input groups logically similar operations that serve different purposes.

Temporal Cohesion: Elements are grouped because they execute at the same time. A "StartupModule" that initializes the database, loads configuration, starts the web server, and sends a notification groups things that happen at startup but are otherwise unrelated.

Procedural Cohesion: Elements are grouped because they follow a specific execution sequence. They are related by order rather than by function.

Communicational Cohesion: Elements operate on the same data but perform different operations. A module that both validates a customer record and formats it for display operates on the same data for different purposes.

Sequential Cohesion: The output of one element serves as input to the next. A module that reads raw data, parses it, validates it, and transforms it has sequential cohesion—good but could be better.

Functional Cohesion (best): Every element contributes to a single, well-defined function. A "PasswordHasher" module that only contains functions for hashing passwords, verifying hashes, and generating salts has functional cohesion—everything relates to one purpose.

Coupling: External Dependencies

Coupling measures how much one module depends on another. High coupling means changes in one module cascade into other modules. Low coupling means modules can be modified independently.

Types of Coupling (Worst to Best)

Content Coupling (worst): One module directly accesses or modifies another module's internal data or code. Module A reaches into Module B's private variables or jumps into the middle of Module B's code.

Common Coupling: Modules share global data. Multiple modules read and write the same global variables, creating invisible dependencies—any module's modification of global state affects all others.

External Coupling: Modules share an externally imposed data format, communication protocol, or device interface. Changing the external format requires modifying all coupled modules.

Control Coupling: One module passes control information (flags, mode indicators) that tells another module what to do. The calling module must understand the internal logic of the called module.

python example

# Control coupling - caller controls callee's behavior with flags
def process_data(data, mode):
    if mode == "validate":
        return validate(data)
    elif mode == "transform":
        return transform(data)
    elif mode == "export":
        return export(data)
# Better: separate functions, let the caller choose which to call

Stamp Coupling: Modules pass complex data structures but only use part of the passed data. Module A passes an entire Customer object when Module B only needs the email address.

Data Coupling (best): Modules communicate only through parameters—each parameter is a simple piece of data actually needed by the called module. This is the loosest form of coupling.

python example

# Data coupling - only necessary data is passed
def send_notification(email_address: str, message: str) -> bool:
    # Only receives what it actually needs
    pass

Real-World Example: Refactoring for Better Cohesion/Coupling

Before (low cohesion, high coupling):

python example

class OrderManager:
    def create_order(self, items, customer):
        # Validates inventory (inventory concern)
        # Calculates pricing (pricing concern)
        # Processes payment (payment concern)
        # Updates inventory (inventory concern)
        # Sends confirmation email (notification concern)
        # Generates invoice PDF (document concern)
        # Updates analytics (reporting concern)
        pass

This class has low cohesion (mixes 6+ different concerns) and high coupling (depends on inventory, payment, email, PDF, and analytics systems).

After (high cohesion, low coupling):

python example

class OrderService:           # Only orchestrates order flow
class InventoryService:       # Only manages stock
class PricingService:         # Only calculates prices  
class PaymentService:         # Only handles payments
class NotificationService:    # Only sends notifications
class InvoiceService:         # Only generates documents

Each class has functional cohesion (one responsibility) and data coupling (communicates via simple parameters or domain objects).

Measuring in Practice

Tools like SonarQube, Structure101, and NDepend calculate coupling metrics automatically. Key indicators: classes with more than 7-10 dependencies (high coupling), methods longer than 20 lines (potential cohesion issues), and packages with many circular dependencies (structural problems).

The Design Goal

High cohesion + Low coupling = modules that are easy to understand (focused purpose), easy to test (few dependencies to mock), easy to modify (changes are localized), and easy to reuse (minimal baggage). Every design decision should be evaluated against these twin goals.

Cohesion: Internal Strength

Types of Cohesion (Worst to Best)

Procedural Cohesion: Elements are grouped because they follow a specific execution sequence. They are related by order rather than by function.

Coupling: External Dependencies

Coupling measures how much one module depends on another. High coupling means changes in one module cascade into other modules. Low coupling means modules can be modified independently.

Types of Coupling (Worst to Best)

External Coupling: Modules share an externally imposed data format, communication protocol, or device interface. Changing the external format requires modifying all coupled modules.

Control Coupling: One module passes control information (flags, mode indicators) that tells another module what to do. The calling module must understand the internal logic of the called module.

python example

# Control coupling - caller controls callee's behavior with flags
def process_data(data, mode):
    if mode == "validate":
        return validate(data)
    elif mode == "transform":
        return transform(data)
    elif mode == "export":
        return export(data)
# Better: separate functions, let the caller choose which to call

Stamp Coupling: Modules pass complex data structures but only use part of the passed data. Module A passes an entire Customer object when Module B only needs the email address.

Data Coupling (best): Modules communicate only through parameters—each parameter is a simple piece of data actually needed by the called module. This is the loosest form of coupling.

python example

# Data coupling - only necessary data is passed
def send_notification(email_address: str, message: str) -> bool:
    # Only receives what it actually needs
    pass

Real-World Example: Refactoring for Better Cohesion/Coupling

Before (low cohesion, high coupling):

python example

class OrderManager:
    def create_order(self, items, customer):
        # Validates inventory (inventory concern)
        # Calculates pricing (pricing concern)
        # Processes payment (payment concern)
        # Updates inventory (inventory concern)
        # Sends confirmation email (notification concern)
        # Generates invoice PDF (document concern)
        # Updates analytics (reporting concern)
        pass

This class has low cohesion (mixes 6+ different concerns) and high coupling (depends on inventory, payment, email, PDF, and analytics systems).

After (high cohesion, low coupling):

python example

class OrderService:           # Only orchestrates order flow
class InventoryService:       # Only manages stock
class PricingService:         # Only calculates prices  
class PaymentService:         # Only handles payments
class NotificationService:    # Only sends notifications
class InvoiceService:         # Only generates documents

Each class has functional cohesion (one responsibility) and data coupling (communicates via simple parameters or domain objects).

Cohesion and Coupling — Software Engineering

Cohesion: Internal Strength

Types of Cohesion (Worst to Best)

Coupling: External Dependencies

Types of Coupling (Worst to Best)

Real-World Example: Refactoring for Better Cohesion/Coupling

Measuring in Practice

The Design Goal

Continue learning this concept

Cohesion and Coupling — Software Engineering

Cohesion: Internal Strength

Types of Cohesion (Worst to Best)

Coupling: External Dependencies

Types of Coupling (Worst to Best)

Real-World Example: Refactoring for Better Cohesion/Coupling

Measuring in Practice

The Design Goal

Continue learning this concept