GRASP gives you practical responsibility-assignment tools for deciding who should know, create, and coordinate.

Why it matters in real Java systems

In order-management workflows, teams repeatedly face choices such as where totals should be calculated, who should create order lines, and whether a controller or use case object should coordinate checkout. GRASP offers practical heuristics for those decisions.

The design idea behind this topic

GRASP patterns help prevent responsibility from drifting into the wrong layers. Information Expert pushes behavior toward the object that knows enough to do the job. Creator encourages more natural object construction relationships. Controller keeps system event handling from leaking into UI or transport code.

These are not rigid rules. They are heuristics that guide design conversations. In Java applications, GRASP often improves both domain models and application-service boundaries.

For long-lived systems, these heuristics matter because bad responsibility assignment compounds into coupling, low cohesion, and unclear architecture.

Key ideas to hold onto

Java example in the Order Management domain

package org.javaomnibus.ecommerce.principles;

import java.util.ArrayList;
import java.util.List;

public final class CheckoutController {
    public Order submit(CheckoutRequest request) {
        Cart cart = new Cart();
        for (CheckoutItem item : request.items()) {
            cart.addItem(item.sku(), item.quantity(), item.unitPrice());
        }
        return Order.fromCart(request.customerId(), cart);
    }
}

final class Cart {
    private final List lines = new ArrayList<>();

    void addItem(String sku, int quantity, Money unitPrice) {
        lines.add(new CartLine(sku, quantity, unitPrice));
    }

    Money total() {
        return lines.stream().map(CartLine::lineTotal).reduce(Money.zero(), Money::add);
    }

    List lines() {
        return List.copyOf(lines);
    }
}

final class Order {
    static Order fromCart(String customerId, Cart cart) {
        return new Order(customerId, cart.lines(), cart.total());
    }

    private Order(String customerId, List lines, Money total) {}
}

record CheckoutRequest(String customerId, List items) {}
record CheckoutItem(String sku, int quantity, Money unitPrice) {}
record CartLine(String sku, int quantity, Money unitPrice) {
    Money lineTotal() { return unitPrice.multiply(quantity); }
}
record Money(java.math.BigDecimal amount) {
    static Money zero() { return new Money(java.math.BigDecimal.ZERO); }
    Money add(Money other) { return new Money(amount.add(other.amount)); }
    Money multiply(int quantity) { return new Money(amount.multiply(java.math.BigDecimal.valueOf(quantity))); }
}

Step by step

1. Cart is the information expert for total calculation because it owns the lines.
2. Order acts as creator through a factory-style method that converts cart information into an order.
3. CheckoutController coordinates the system event rather than embedding business calculations itself.
4. The responsibilities line up with who knows what and who should coordinate what.

Where this shows up in practice

• Use-case orchestration in web and messaging-driven Java applications
• Responsibility assignment during domain modeling workshops
• Refactoring code where controllers or services have absorbed too much logic

When not to over-apply it

GRASP heuristics can point in different directions at the same time. That is normal. They are decision aids, not absolute formulas. You still need judgment about coupling, cohesion, and boundary clarity.

Frequent mistakes to watch for

• Treating controllers as places for all business logic
• Ignoring information expert and pushing calculations into unrelated services
• Using Creator mechanically when a clearer factory or builder abstraction would work better
• Forgetting that application controllers and framework controllers are not always the same thing

Related concepts