Java Design Patterns — A Field Guide for Working Backend Engineers

The Over-Abstraction Trap: Patterns as Chains

The most common failure mode in modern Java backend engineering isn't a lack of design patterns; it's the recursive application of them until the intent is buried under five layers of indirection. We’ve all seen the AbstractTransactionalBaseProxyFactory that exists solely to instantiate a single service.

In a distributed system, every abstraction adds a cognitive tax. If a developer has to open four files to understand how a single POST request is processed, the architecture has failed. We use patterns to manage complexity, not to signal that we’ve read a textbook. When p99 latency spikes because of a bottleneck in a reflection-heavy DynamicProxy, no amount of "clean code" justification matters.

The Strategy Pattern vs. The Branching Hellscape

Consider a payment processing gateway. The naive approach—and the one that inevitably leads to a 2,000-line service class—is the nested if-else or switch block.

// THE WRONG WAY: The God-Method Switch
public void processPayment(PaymentRequest req) {
    if (req.getGateway().equals("STRIPE")) {
        // 50 lines of Stripe-specific SDK logic
    } else if (req.getGateway().equals("ADYEN")) {
        // 50 lines of Adyen-specific logic
    } else if (req.getGateway().equals("PAYPAL")) {
        // 50 lines of PayPal-specific logic
    }
}

This violates the Open/Closed Principle. Adding a new provider requires modifying a core service, increasing the risk of regression in unrelated payment flows.

The Strategy Pattern is the antidote, but it’s often over-engineered with manual registries. In a modern Spring-based Java environment, we can leverage dependency injection to build a clean, scalable registry.

```java
// THE RIGHT WAY: Polymorphic Strategy Registry
public interface PaymentProvider {
    boolean supports(GatewayType type);
    PaymentResponse execute(PaymentRequest request);
}

@Service @RequiredArgsConstructor public class StripeProvider implements PaymentProvider { @Override public boolean supports(GatewayType type) { return type == GatewayType.STRIPE; }

@Override public PaymentResponse execute(PaymentRequest request) { // Isolated Stripe logic } }

@Service @RequiredArgsConstructor public class PaymentService { private final List<PaymentProvider> providers;

public PaymentResponse process(PaymentRequest request) { return providers.stream() .filter(p -> p.supports(request.getGateway())) .findFirst() .orElseThrow(() -> new UnsupportedOperationException("No gateway found")) .execute(request); } } ```

By using a List<PaymentProvider> injection, the PaymentService never needs to change. New providers are simply discovered at runtime. This reduced our deployment risk in one project from a "scary core change" to a "sidecar addition," dropping our QA cycle for new integrations from three days to four hours.

Decorator Patterns vs. The Interceptor Bloat

When engineers want to add logging, caching, or rate limiting to a service, they often default to Aspect-Oriented Programming (AOP) with custom annotations like @LogExecutionTime. While AOP is powerful, it creates "magic" behavior that is difficult to debug and invisible to static analysis.

The "wrong" way is hiding critical business side-effects in an @Around advice that developers forget exists. If the caching logic fails, the stack trace becomes a nightmare of Proxies and Interceptors.

Instead, use the Decorator Pattern to wrap core logic. This makes the execution chain explicit.

[ Controller ] 
      |
[ RateLimitingDecorator ]  <-- Check headers/IP
      |
[ CachingDecorator ]       <-- Check Redis
      |
[ ActualServiceImplementation ] <-- The "Real" Work

The implementation relies on the fact that the decorator implements the same interface as the service it wraps.

```java
public class CachingOrderService implements OrderService {
    private final OrderService delegate;
    private final CacheManager cache;

@Override public Order findById(Long id) { return cache.get(id, () -> delegate.findById(id)); } } ```

This is superior to AOP for one primary reason: Unit Testing. You can test the cache logic by passing a mock OrderService to the decorator without spinning up a full Spring Context or dealing with ByteBuddy-generated proxies.

The Builder Pattern: Beyond Lombok’s `@Builder`

We use the Builder pattern to avoid "Telescoping Constructors" (User(id), User(id, name), User(id, name, email)...). However, the common anti-pattern is using a Builder that allows the creation of inconsistent objects. If your Builder allows me to call .build() without a mandatory email field, the pattern is just a glorified setter-collection.

A truly robust Builder uses a Fluent Step Interface to enforce mandatory fields at compile time.

```java
// THE WRONG WAY: Permissive Builder
User u = User.builder().name("John").build(); // Missing required Email!

// THE RIGHT WAY: Static Type-Safe Stepper public class User { private final String name; private final String email;

private User(String name, String email) { this.name = name; this.email = email; }

public static NameStep builder() { return new Builder(); }

public interface NameStep { EmailStep withName(String name); } public interface EmailStep { User withEmail(String email); }

private static class Builder implements NameStep, EmailStep { private String name; @Override public EmailStep withName(String name) { this.name = name; return this; }

@Override public User withEmail(String email) { return new User(this.name, email); } } }

// Usage (Compiler enforced): User u = User.builder() .withName("John") .withEmail("john@example.com"); // build() isn't even selectable until email is provided ```

This prevents the "Incomplete Object" runtime errors that often plague large-scale Java batch processors. In a high-throughput system handling 10k events/sec, catching a missing field at compile time vs. seeing it bubble up as a NullPointerException inside a deep persistence layer saves hours of log diving.

The Singleton vs. The Scoped Component

The public static final Singleton INSTANCE is the most abused pattern in Java. In a multi-threaded backend, singletons often become contention points.

The anti-pattern is the "Global State Singleton." I once audited a system where a ConfigurationManager singleton held a HashMap of settings. Under heavy load (2,000 concurrent requests), the synchronized keyword on the get() method caused p99 latency to explode from 40ms to 900ms. The threads were simply waiting in line for a lock on a map that rarely changed.

In modern Java, you should almost never write your own Singleton. Let the IoC container (Spring/Guice) manage the lifecycle. If you need global state, use Immutable data structures or ConcurrentHashMap with computeIfAbsent to avoid lock contention.

Hard Lesson: Replacing a synchronized Singleton with a volatile reference to an immutable Configuration object dropped our lock wait time to zero and halved our CPU usage on the API gateway layer.

The Observer Pattern and the Eventual Consistency Lie

The Observer pattern is often implemented synchronously: when A happens, call B, C, and D in the same thread.

// THE WRONG WAY: Synchronous Observer
public void completeOrder(Order o) {
    db.save(o);
    emailService.send(o); // What if SMTP is slow?
    inventoryService.update(o); // What if this fails?
}

This transforms a simple database write into a distributed transaction nightmare. If inventoryService fails, do you roll back the DB? Does the user get an error for an order that actually saved?

The correct "Backend" version of the Observer pattern is Asynchronous Event Driven Architecture. In Java, this means using an ApplicationEventMulticaster or an external message broker like RabbitMQ or Kafka.

```java
// THE RIGHT WAY: Decoupled Events
@Transactional
public void completeOrder(Order o) {
    db.save(o);
    eventPublisher.publishEvent(new OrderCompletedEvent(o));
}

@Async @EventListener public void handleEmail(OrderCompletedEvent event) { // Retries can happen here without blocking the user } ```

The critical detail here is the @TransactionalEventListener. It ensures the observer only triggers if the database transaction actually commits. Running this asynchronously decoupled our order ingestion from our third-party integrations, ensuring that a 500ms lag from a transactional email provider didn't impact our order success rate.

State Pattern vs. Enum Flag Hell

If your object has a status field and your methods are littered with if (status == PENDING && action == CANCEL), you are living in "State Hell." It’s brittle and impossible to visualize.

The State Pattern moves the logic into state-specific classes. This is particularly vital for long-running workflows like insurance claims or CI/CD pipelines.

```java
public interface OrderState {
    void transitionToNext(OrderContext ctx);
}

public class PaidState implements OrderState { @Override public void transitionToNext(OrderContext ctx) { ctx.setState(new ShippedState()); // Trigger logistics logic } } ```

Instead of a monolithic OrderProcessor containing all logic for every possible state, each state class handles its own transitions. This isolation makes the code "locally readable"—which is the only kind of readability that matters in a codebase with 100k+ lines of code.

The Factory Pattern and the Reflexive Instantiation Bug

Factory patterns are often used to hide the complexity of object creation. The anti-pattern is the "String-based Dynamic Factory" using Class.forName().

// THE WRONG WAY: Reflection Factory
public Worker getWorker(String type) {
    return (Worker) Class.forName("com.app.workers." + type + "Worker").newInstance();
}

This is a security risk (injection), a performance hit (reflection), and it breaks ProGuard/GraalVM native image obfuscation.

In a modern Java backend, the Static Factory Method or a Type-Mapped Supplier Factory is the standard. Use an EnumMap<WorkerType, Supplier<Worker>> to map types to constructors. It is type-safe, allows for pre-instantiation or lazy loading, and is roughly 20x faster than reflection-based instancing in high-frequency loops.

Pruning the Pattern Index

Design patterns are not Lego bricks; they are more like surgical tools. You don't use a scalpel to open a cardboard box.

The biggest indicator of seniority in a backend engineer isn't knowing how to implement a Visitor pattern; it's knowing when a simple for-each loop is better. We reached a point in one of our core services where we deleted a complex Command pattern implementation and replaced it with a simple Map<String, Consumer<Request>>. The result? The code shrunk by 400 lines, the memory footprint decreased because we weren't creating thousands of short-lived Command objects, and the "On-boarding time" for new hires dropped because they didn't have to learn a custom DSL just to add a new API endpoint.

If your pattern requires a README to explain why it exists, it might be the wrong pattern. The best architectures use patterns that are so intuitive they feel like a natural extension of the language, not a layer of bureaucracy on top of it. Choose patterns that make the code self-documenting at the call site, not the implementation site.

What this guide consolidates

The classic Gang-of-Four patterns each had a short page. They have been merged into this single field guide so you can compare them — most real codebases use two or three of these together, rarely just one.

Singleton Pattern in Java

Definition

Ensure a class has exactly one instance with a global access point.

Naive (broken)

public class Cache {
  private static Cache INSTANCE;
  public static Cache get() {
    if (INSTANCE == null) INSTANCE = new Cache();
    return INSTANCE;
  }
}

Two threads can both see null.

Thread-safe with double-checked locking

public class Cache {
  private static volatile Cache INSTANCE;
  public static Cache get() {
    Cache local = INSTANCE;
    if (local == null) {
      synchronized (Cache.class) {
        local = INSTANCE;
        if (local == null) INSTANCE = local = new Cache();
      }
    }
    return local;
  }
}

Cleanest: enum

public enum Cache {
  INSTANCE;
  public void put(String k, Object v) { /* ... */ }
}

JVM guarantees a single instance, serialization-safe.

When NOT to use

• Introduces global state.
• In Spring, beans are singletons by default — use them.

Related tutorials

• Factory Pattern Java
• Essential Design Principles
• Dependency Inversion Principle

Factory Pattern Explained with Real Examples

Definition

Move the decision of which concrete class to instantiate out of the caller.

Problem

Notification n = switch (type) {
  case EMAIL -> new EmailNotification(smtpHost, port);
  case SMS   -> new SmsNotification(twilioKey);
  case PUSH  -> new PushNotification(fcmKey);
};

With a factory

```java
interface NotificationFactory { Notification create(Type type); }

class DefaultNotificationFactory implements NotificationFactory { private final Config cfg; DefaultNotificationFactory(Config cfg) { this.cfg = cfg; } public Notification create(Type type) { return switch (type) { case EMAIL -> new EmailNotification(cfg.smtpHost, cfg.smtpPort); case SMS -> new SmsNotification(cfg.twilioKey); case PUSH -> new PushNotification(cfg.fcmKey); }; } } ```

Variants

• Simple Factory — one method picks a class.
• Factory Method — subclasses override to choose the type.
• Abstract Factory — factory of factories, creates families.

Real Java examples

• Calendar.getInstance()
• Logger.getLogger(name)
• Executors.newFixedThreadPool(n)

Related tutorials

• Builder Pattern Java
• Singleton Pattern Java
• Strategy Pattern Java

Builder Pattern for Clean Object Creation

Definition

Separate construction from representation.

Problem: telescoping constructors

new Pizza(12, true, false, true, true, false, "thin");

Builder solution

```java
public class Pizza {
  private final int size;
  private final boolean cheese, pepperoni, mushrooms;

private Pizza(Builder b) { this.size = b.size; this.cheese = b.cheese; this.pepperoni = b.pepperoni; this.mushrooms = b.mushrooms; }

public static class Builder { private final int size; private boolean cheese, pepperoni, mushrooms; public Builder(int size) { this.size = size; } public Builder cheese() { this.cheese = true; return this; } public Builder pepperoni() { this.pepperoni = true; return this; } public Builder mushrooms() { this.mushrooms = true; return this; } public Pizza build() { return new Pizza(this); } } }

Pizza p = new Pizza.Builder(12).cheese().pepperoni().build(); ```

With Lombok

@Value @Builder
public class Pizza { int size; boolean cheese; boolean pepperoni; boolean mushrooms; }

When to use

• ≥3-4 fields, many optional.
• Want immutability.

Related tutorials

• Factory Pattern Java
• Singleton Pattern Java
• Essential Design Principles

Strategy Pattern for Flexible Business Logic

Definition

Define a family of interchangeable algorithms; let the client choose.

Without Strategy

double shippingCost(Order o, String mode) {
  return switch (mode) {
    case "STANDARD" -> o.weight() * 0.5;
    case "EXPRESS"  -> o.weight() * 1.5 + 10;
    case "PICKUP"   -> 0;
    default -> throw new IllegalArgumentException();
  };
}

With Strategy

```java
interface ShippingStrategy { double cost(Order o); }

class Standard implements ShippingStrategy { public double cost(Order o){return o.weight()*0.5;} } class Express implements ShippingStrategy { public double cost(Order o){return o.weight()*1.5+10;} }

class Checkout { private final ShippingStrategy strategy; Checkout(ShippingStrategy s) { this.strategy = s; } double shipping(Order o) { return strategy.cost(o); } } ```

In Spring Boot

@Service
class ShippingService {
  private final Map<String, ShippingStrategy> strategies;
  ShippingService(List<ShippingStrategy> all) {
    this.strategies = all.stream().collect(toMap(s -> s.getClass().getSimpleName(), s -> s));
  }
}

Strategy vs State vs Command

• Strategy — choose how to do something.
• State — behavior based on what the object is.
• Command — encapsulate a request as an object.

Related tutorials

• Open Closed Principle
• Factory Pattern Java
• Observer Pattern Java

Observer Pattern in Event-Driven Systems

Definition

One-to-many dependency: when one object changes state, observers are notified.

Plain Java

```java
interface OrderObserver { void onPlaced(Order o); }

class OrderService { private final List<OrderObserver> observers = new ArrayList<>(); void subscribe(OrderObserver o) { observers.add(o); } void place(Order o) { observers.forEach(obs -> obs.onPlaced(o)); } } ```

With Spring's events

```java
@Service
@RequiredArgsConstructor
class OrderService {
  private final ApplicationEventPublisher events;
  public void place(Order o) {
    events.publishEvent(new OrderPlacedEvent(o));
  }
}

@Component class EmailListener { @EventListener void on(OrderPlacedEvent e) { /* send confirmation */ } } ```

Adding a new reaction = new EventListener. Zero changes to OrderService.

Async

@Async
@EventListener
void on(OrderPlacedEvent e) { /* runs on a task executor */ }

Pitfalls

• Hidden control flow.
• For cross-process events, use a real broker (Kafka, RabbitMQ).

Related tutorials

• Strategy Pattern Java
• Decorator Pattern Java
• Essential Design Principles

Decorator Pattern Explained Simply

Definition

Wrap an object to add behavior while keeping the same interface. Stack decorators to compose features.

Example

```java
interface Greeter { String greet(String name); }

class PlainGreeter implements Greeter { public String greet(String name) { return "Hello, " + name; } }

class ShoutingDecorator implements Greeter { private final Greeter inner; ShoutingDecorator(Greeter g) { this.inner = g; } public String greet(String name) { return inner.greet(name).toUpperCase() + "!"; } }

class TimingDecorator implements Greeter { private final Greeter inner; TimingDecorator(Greeter g) { this.inner = g; } public String greet(String name) { long t = System.nanoTime(); try { return inner.greet(name); } finally { System.out.println("took " + (System.nanoTime()-t) + "ns"); } } }

Greeter g = new TimingDecorator(new ShoutingDecorator(new PlainGreeter())); ```

Real-world examples

• java.io streams: new BufferedReader(new InputStreamReader(System.in))
• HTTP clients with logging / retry / metrics interceptors
• Spring AOP (Cacheable, Transactional, Retryable)

When to use

• Add orthogonal features.
• Composable in any order.

Related tutorials

• Adapter Pattern Spring Boot
• Strategy Pattern Java
• Composition Over Inheritance

Adapter Pattern in Spring Boot

Definition

Wrap an existing class with a new interface so it can work with code that expects something different.

Example

Your interface:

public interface Notifier { void send(String to, String message); }

Third-party SDK:

public class TwilioSdk {
  public void dispatchSms(SmsPayload p) { /* ... */ }
}

Adapter:

@Component
public class TwilioNotifier implements Notifier {
  private final TwilioSdk sdk;
  public TwilioNotifier(TwilioSdk sdk) { this.sdk = sdk; }
  @Override
  public void send(String to, String message) {
    var payload = new SmsPayload();
    payload.setTo(to); payload.setBody(message);
    sdk.dispatchSms(payload);
  }
}

Benefits

• Third-party API isolated to one file.
• Easier tests.
• Honors DIP.

Adapter vs Decorator vs Facade

• Adapter — same behavior, different interface.
• Decorator — same interface, added behavior.
• Facade — simpler interface in front of a set of classes.

Related tutorials

• Decorator Pattern Java
• Dependency Inversion Principle
• Factory Pattern Java