Coupling and Cohesion

When exploring the world of software architecture, you will inevitably come across two foundational concepts: Coupling and Cohesion. These twin pillars shape how the different pieces of your codebase interact with each other, and they end up deciding how maintainable and scalable your project stays over time. They're not just standalone ideas either — low cohesion and high coupling are usually the root cause behind violations of several SOLID principles, especially Single Responsibility, Open/Closed, and Dependency Inversion.

Let's dive in and explore what these terms mean, why they are so important, and how they look in practice using Python.

What is Cohesion?

Cohesion refers to the degree to which the elements inside a single module or class belong together. It measures the strength of the relationship between the responsibilities of a single component.

• High Cohesion (Good): A highly cohesive class is focused and does one thing very well. All of its methods and properties are closely related to a single, well-defined purpose.
• Low Cohesion (Bad): A module with low cohesion tries to do too many unrelated things. It acts like a "junk drawer" of functions, making it hard to understand and test.

What is Coupling?

Coupling describes the degree of interdependence between software modules. It measures how closely connected two routines or modules are and the strength of the relationships between them.

• Low Coupling (Good): Modules are relatively independent. A change in one module is unlikely to require changes in another. This makes the system more modular and resilient.
• High Coupling (Bad): Modules are tightly intertwined. Changing a piece of code in one place often breaks code in another, leading to a fragile and rigid system.

Why Are They Important?

Striving for High Cohesion and Low Coupling is the golden rule of software engineering. Here is why:

1. Maintainability: Code that is loosely coupled and highly cohesive is much easier to read, understand, and update.
2. Reusability: Highly cohesive modules that don't depend heavily on other parts of the system can easily be extracted and reused in other projects.
3. Testability: When a class only does one thing (high cohesion) and doesn't rely on a dozen other classes (low coupling), writing unit tests becomes a breeze.
4. Reduced Risk: Changes in a loosely coupled system are localized. You minimize the risk of introducing cascading bugs across your codebase.

A Practical Example in Python

Let's look at an example to crystallize these concepts — and then see what happens when a new requirement shows up later, which is really where coupling and cohesion prove their worth.

The Bad Way: High Coupling & Low Cohesion

In this example, the OrderProcessor class is doing too much (low cohesion) and is directly tied to a specific payment gateway implementation (high coupling).

class StripePaymentGateway:
    def charge(self, amount):
        print(f"Charging ${amount} via Stripe")

class OrderProcessor:
    def __init__(self):
        # High Coupling: Hardcoded dependency
        self.gateway = StripePaymentGateway()

    def process_order(self, order):
        # Low Cohesion: Mixing business logic with presentation and database concerns
        print("Validating order...")
        print("Saving order to database...")
        self.gateway.charge(order['total'])
        print("Sending email receipt to customer...")

The Good Way: Low Coupling & High Cohesion

Now, let's refactor this. We will split the responsibilities (increasing cohesion) and use dependency injection (decreasing coupling).

# High Cohesion: Each class has a single responsibility

class PaymentGateway:
    def charge(self, amount):
        pass

class StripePaymentGateway(PaymentGateway):
    def charge(self, amount):
        print(f"Charging ${amount} via Stripe")

class OrderValidator:
    def validate(self, order):
        print("Validating order...")

class OrderRepository:
    def save(self, order):
        print("Saving order to database...")

class EmailService:
    def send_receipt(self):
        print("Sending email receipt to customer...")

class OrderProcessor:
    def __init__(self, gateway: PaymentGateway, validator: OrderValidator, repo: OrderRepository, emailer: EmailService):
        # Low Coupling: Dependencies are injected, relying on abstractions
        self.gateway = gateway
        self.validator = validator
        self.repo = repo
        self.emailer = emailer

    def process_order(self, order):
        self.validator.validate(order)
        self.repo.save(order)
        self.gateway.charge(order['total'])
        self.emailer.send_receipt()

Six Months Later: A New Requirement Arrives

Say the business now wants to support PayPal as well as Stripe. This is exactly the kind of future change that reveals whether your design was actually good, not just tidy.

With the bad version, you have no choice but to open up OrderProcessor and start editing its internals:

class OrderProcessor:
    def __init__(self, use_paypal=False):
        # Every new payment option means editing this class again
        if use_paypal:
            self.gateway = PayPalPaymentGateway()
        else:
            self.gateway = StripePaymentGateway()
        # ...validation, saving, and emailing logic still tangled in here too

Every new gateway means touching OrderProcessor again, and every touch risks breaking validation, saving, or emailing since they all live in the same place.

With the good version, you just write the new class and pass it in — OrderProcessor doesn't change at all:

class PayPalPaymentGateway(PaymentGateway):
    def charge(self, amount):
        print(f"Charging ${amount} via PayPal")

# OrderProcessor's own code is untouched
paypal_processor = OrderProcessor(
    gateway=PayPalPaymentGateway(),
    validator=OrderValidator(),
    repo=OrderRepository(),
    emailer=EmailService()
)
paypal_processor.process_order({'total': 49.99})

That's the real payoff of low coupling: it's not about how the code looks today, it's about how little you have to touch when tomorrow's requirement shows up.

In Conclusion

Understanding coupling and cohesion is essential for crafting robust software. By ensuring that your modules have a single, clear purpose and interact with each other through clean, well-defined boundaries, you lay the foundation for a codebase that is a joy to work with.

Happy coding!