Coupling and cohesion are the quickest lenses for judging whether a design will get easier or harder to change.

Why it matters in real Java systems

In business systems, most pain comes from change amplification. A new refund rule touches order logic, payment handling, shipment reversal, and customer messaging. If a class or package has low cohesion and high coupling, small requests become high-risk edits. That is why this topic belongs early in the learning sequence.

The design idea behind this topic

High cohesion means a type or module has a clear center of gravity. In OOAD, that usually means one business purpose or one small cluster of closely related concerns.

Low coupling means fewer fragile dependencies. Java systems achieve this through stable interfaces, focused collaborators, better package boundaries, and models that own their own rules.

One of the easiest review questions you can ask is: “If this business rule changes, how many files should need to care?” That question often exposes both coupling and cohesion problems immediately.

Key ideas to hold onto

Java example in the Order Management domain

package org.javaomnibus.ecommerce.foundations;

public final class PlaceOrderUseCase {
    private final InventoryReservationPolicy inventoryReservationPolicy;
    private final PaymentAuthorizer paymentAuthorizer;
    private final ConfirmationNotifier confirmationNotifier;

    public PlaceOrderUseCase(
        InventoryReservationPolicy inventoryReservationPolicy,
        PaymentAuthorizer paymentAuthorizer,
        ConfirmationNotifier confirmationNotifier
    ) {
        this.inventoryReservationPolicy = inventoryReservationPolicy;
        this.paymentAuthorizer = paymentAuthorizer;
        this.confirmationNotifier = confirmationNotifier;
    }

    public void handle(Order order) {
        inventoryReservationPolicy.reserve(order);
        paymentAuthorizer.authorize(order);
        confirmationNotifier.notify(order);
    }
}

interface InventoryReservationPolicy { void reserve(Order order); }
interface PaymentAuthorizer { void authorize(Order order); }
interface ConfirmationNotifier { void notify(Order order); }
record Order(String orderId) {}

Step by step

1. PlaceOrderUseCase stays cohesive: it coordinates one business use case.
2. InventoryReservationPolicy, PaymentAuthorizer, and ConfirmationNotifier each own one narrow responsibility.
3. The use case is coupled to abstractions, but the coupling is focused and intentional.
4. If notification behavior changes, payment logic does not need to change with it.

Where this shows up in practice

• Refactoring service classes that have absorbed unrelated responsibilities
• Evaluating whether package boundaries match business responsibilities
• Reviewing whether a use case is coupled to too many technical details

When not to over-apply it

Pursuing perfect decoupling can create too many tiny abstractions. The goal is not minimal dependencies at all cost. It is dependencies that line up with stable, meaningful boundaries.

Frequent mistakes to watch for

• Calling a design low-coupled just because it uses interfaces everywhere
• Splitting responsibilities so aggressively that the model becomes fragmented and hard to follow
• Ignoring package-level coupling while focusing only on class-level cleanups
• Leaving orchestration classes with too many unrelated reasons to change

Related concepts