Pattern choice gets easier when you ask what force is hurting the design, not which pattern name sounds familiar.

Developers usually struggle with patterns not because the patterns are complicated, but because the choice feels ambiguous. This page is about turning pattern selection into a force-based decision: what kind of variation is growing, what kind of coupling is hurting, and what kind of creation or behavior is becoming too awkward?

OOAD landing page Learning roadmap Previous: GoF Patterns Overview and Catalog Next: GoF Patterns Cheatsheet for Java

Why This Topic Matters

Why it matters in real Java systems

In Java commerce flows, one problem might be gateway creation, another might be optional behavior layering, and another might be state-driven workflow logic. The right pattern is clearer when the force is named clearly.

Core Explanation

The design lens behind this page

The fastest way to choose patterns well is to stop asking “which pattern should I use?” in the abstract. Ask instead: what is the pressure? Is object creation full of branching? Is behavior changing by runtime condition? Are clients depending on shapes they should not need to know?

Pattern choice also improves when you compare near neighbors. Factory Method, Abstract Factory, and Builder solve related but different creation problems. Strategy, State, and Command can all look like “behavior moved into objects,” but the reasons they exist are different.

Good pattern choice is less about catalog recall and more about distinguishing forces precisely enough that one response becomes a better fit than the others.

Concept Breakdown

Key ideas to hold onto

Concept

Creation pain

If building objects is becoming conditional, repetitive, or configuration-heavy, the creational family is usually the first place to look.

Concept

Boundary pain

If interfaces do not align or wrappers are proliferating, structural patterns are often relevant.

Concept

Workflow pain

If behavior varies by state, request type, or collaborator chain, behavioral patterns are usually the stronger lens.

Java Example

Java example in the Order Management domain

Java example: one design that could branch toward different patterns

package org.javaomnibus.ecommerce.gof;

public final class CheckoutContext {
    public PaymentGateway gatewayFor(Order order) {
        if ("CARD".equals(order.paymentMethod())) {
            return new CardGateway();
        }
        if ("WALLET".equals(order.paymentMethod())) {
            return new WalletGateway();
        }
        throw new IllegalArgumentException("Unsupported method");
    }

    public Money applyDiscount(Order order) {
        if (order.isPremiumCustomer()) {
            return order.total().multiply(95).divide(100);
        }
        return order.total();
    }
}

Code Walkthrough

Step by step

Gateway creation suggests a creational refactor such as Factory Method.
Discount variation suggests a behavioral refactor such as Strategy.
One class is carrying unrelated forces, which is exactly why pattern choice starts with force diagnosis.
The same code can point toward different patterns depending on which pain you are trying to relieve.

Real-World Usage

Where this helps in practice

Pattern reviews during design sessions
Coaching developers who know the names but not the decision criteria
Choosing between near-neighbor patterns in refactoring work

Trade-Offs

When to be careful

Forcing every design pressure into a named pattern can create unnecessary abstraction. Some problems are still better solved by straightforward refactoring without a formal pattern structure.

Common Mistakes

Frequent mistakes to watch for

Choosing by familiarity instead of by force
Confusing pattern similarity with pattern equivalence
Ignoring simpler refactorings that solve the same problem cleanly
Selecting a pattern before isolating the most painful design pressure

Related concepts

GoF overview and catalog Factory vs Abstract Factory vs Builder Anti-pattern overview