Cohesion — how strongly related the responsibilities inside a module are

Definition

Cohesion measures how strongly related the responsibilities inside a single module or class are. A highly cohesive class does one thing and everything in it supports that one thing. A low-cohesion class bundles unrelated responsibilities together, making it harder to understand, test, and change without side effects. Cohesion and coupling are the two fundamental axes of module quality — high cohesion and low coupling is the target.

In Practice

<?php
// LOW cohesion: this class handles PDF generation, email, AND logging
class OrderProcessor
{
    public function process(Order $order): void
    {
        // business logic
        $order->markConfirmed();

        // PDF generation — unrelated responsibility
        $pdf = $this->generatePdf($order);

        // Email — another unrelated responsibility
        Mail::send('order-confirmed', ['order' => $order]);

        // Logging — yet another responsibility
        Log::info('Order processed', ['id' => $order->id]);
    }
}

// HIGH cohesion: each class has one clear job
class OrderConfirmationService
{
    public function confirm(Order $order): void
    {
        $order->markConfirmed();
    }
}

class OrderPdfGenerator
{
    public function generate(Order $order): string { /* ... */ }
}

High cohesion makes a class easy to name — if you struggle to name a class without using "and" or "manager", it probably has low cohesion. In Laravel projects, low cohesion typically appears in fat models that contain business rules, query scopes, event listeners, and formatting logic all at once. The fix is to extract each responsibility into its own class: a domain service, a query object, a DTO, or an observer.

In Context

Interviewers ask about cohesion to assess whether a candidate thinks at the design level, not just at the syntax level. The expected answer connects cohesion directly to the Single Responsibility Principle: SRP is the rule, high cohesion is the observable outcome when you follow it.

The misconception to watch for: cohesion is not about how many methods a class has, but about whether those methods all serve the same purpose. A class with twenty methods can still be highly cohesive if every method relates to the same concern. A class with three methods can be poorly cohesive if those three methods have nothing to do with each other.

Related terms: coupling (the inter-module dependency axis), SRP (Single Responsibility Principle — the design rule that drives high cohesion), god class (the anti-pattern that emerges from ignoring cohesion), and separation of concerns (the broader architectural principle cohesion applies locally).