When we write software, we often face the same problems again and over. A design pattern is a trusted, reusable solution to one of these common problems. It’s like a blueprint you can adapt to your specific situation. In modern Java, with all its new features, these classic blueprints have become simpler, cleaner, and more powerful to use. I want to walk you through ten practical patterns, showing you how to apply them today with the clarity and efficiency that modern Java allows.

Let’s start with a situation you’ve definitely encountered: you need to validate some text, but the rules change. Sometimes you check for numbers, other times for email formats. The old way meant creating a separate class for each rule. Now, we can use the Strategy Pattern with lambdas.

Think of a strategy as a rule you can swap out. We define what a validation rule looks like with a simple interface. Then, instead of building a whole class for it, we can just write the rule on the spot with a lambda.

public interface ValidationRule {
    boolean check(String input);
}

public class TextValidator {
    private final ValidationRule rule;

    public TextValidator(ValidationRule rule) {
        this.rule = rule;
    }

    public boolean isValid(String input) {
        return rule.check(input);
    }
}

// Using it is now very direct.
TextValidator numberCheck = new TextValidator(s -> s.matches("\\d+"));
TextValidator emailCheck = new TextValidator(s -> s.matches("^[^@]+@[^@]+\\.[^@]+$"));

boolean result = numberCheck.isValid("12345"); // true
boolean result2 = emailCheck.isValid("[email protected]"); // true

The s -> s.matches("\\d+") is the entire strategy. It’s concise, and you can see exactly what it does right where you create the validator. There’s no need to go hunting for a class named NumericValidationStrategy. The logic stays close, which makes your code much easier to follow.

Now, let’s talk about creating objects. Sometimes, a simple constructor isn’t enough. An object might need special setup, or there might be different, named ways to create it. This is where the Factory Pattern shines, and in modern Java, we often use static factory methods.

I find this especially useful with records, which are great for holding plain data. You can put these creation methods right inside the record itself.

public record Product(String id, String label, BigDecimal price) {

    public static Product freeDigitalItem(String id, String label) {
        return new Product(id, label, BigDecimal.ZERO);
    }

    public static Product physicalItem(String id, String label, BigDecimal baseCost) {
        // Add a 20% markup to the cost
        BigDecimal finalPrice = baseCost.multiply(new BigDecimal("1.20"));
        return new Product(id, label, finalPrice);
    }
}

// Creating objects reads like plain English.
Product ebook = Product.freeDigitalItem("EBOOK-101", "Learning Java");
Product textbook = Product.physicalItem("BOOK-202", "Java Reference", new BigDecimal("25.00"));

The method names freeDigitalItem and physicalItem tell you exactly what kind of object you’re getting. These methods can also hide complexity, like calculating a price, or return a cached instance instead of a new one every time. It’s a simple but powerful way to make object creation clearer.

Some objects have many parts, and building them is a process. You might have some required fields and many optional ones. Using a long constructor with lots of parameters is confusing and error-prone. The Builder Pattern solves this by giving you a clear, step-by-step way to construct an object.

You create a special builder class whose only job is to assemble the final object piece by piece.

public class DatabaseConfig {
    private final String host;
    private final int port;
    private final String username;
    private final boolean useSsl;

    // The constructor is private. Only the Builder can use it.
    private DatabaseConfig(Builder builder) {
        this.host = builder.host;
        this.port = builder.port;
        this.username = builder.username;
        this.useSsl = builder.useSsl;
    }

    // The static Builder class
    public static class Builder {
        private String host = "localhost";
        private int port = 5432;
        private String username = "admin";
        private boolean useSsl = false;

        public Builder host(String host) {
            this.host = host;
            return this; // Returns itself for chaining
        }

        public Builder port(int port) {
            this.port = port;
            return this;
        }

        public Builder username(String username) {
            this.username = username;
            return this;
        }

        public Builder useSsl(boolean useSsl) {
            this.useSsl = useSsl;
            return this;
        }

        // The final step that creates the actual object
        public DatabaseConfig build() {
            return new DatabaseConfig(this);
        }
    }
}

// Using the builder is a fluent, readable process.
DatabaseConfig config = new DatabaseConfig.Builder()
        .host("db.myapp.com")
        .port(3306)
        .username("app_user")
        .useSsl(true)
        .build();

You set only the values you care about. The build() method finally creates the DatabaseConfig object, and you can be sure it’s in a complete and valid state because the builder handled all the defaults and steps. It makes complex configuration code much less daunting.

Sometimes, you absolutely need only one instance of a class in your entire application, like a connection pool or a configuration manager. This is the Singleton Pattern. The classic way to do this had some tricky parts with threads and serialization. In modern Java, the simplest and safest way is to use an enum.

An enum with one value is a perfect singleton. The Java language guarantees it.

public enum ApplicationLogger {
    INSTANCE;

    private final Logger logger;

    ApplicationLogger() {
        // This initialization happens only once.
        this.logger = LoggerFactory.getLogger("MainApp");
        logger.setLevel(Level.ALL);
    }

    public Logger get() {
        return logger;
    }
}

// Accessing the single instance is straightforward.
Logger appLogger = ApplicationLogger.INSTANCE.get();
appLogger.info("Application started.");

It’s thread-safe from the start, and it handles serialization correctly. If you don’t need serialization, a static final field is also a good option, but for full protection, the enum is my go-to choice. It’s one of those things that looks almost too simple, but it’s very effective.

What if you have a core object, and you want to add behavior to it without changing its core code? You could extend it with inheritance, but that gets messy fast. The Decorator Pattern offers a better path: wrapping the object.

You create a new class that implements the same interface as the original object. This new class holds a reference to the original, and it adds its own behavior before or after delegating the main task.

public interface PaymentProcessor {
    void process(BigDecimal amount);
}

public class BasicProcessor implements PaymentProcessor {
    @Override
    public void process(BigDecimal amount) {
        // Core logic: charge the amount
        System.out.println("Charging: " + amount);
    }
}

public class AuditingProcessor implements PaymentProcessor {
    private final PaymentProcessor wrappedProcessor;
    private final AuditService auditService;

    public AuditingProcessor(PaymentProcessor processor, AuditService auditService) {
        this.wrappedProcessor = processor;
        this.auditService = auditService;
    }

    @Override
    public void process(BigDecimal amount) {
        // 1. Added behavior: Log the attempt
        auditService.log("Payment attempt for " + amount);
        
        // 2. Delegate to the core logic
        wrappedProcessor.process(amount);
        
        // 3. Added behavior: Log the result
        auditService.log("Payment completed for " + amount);
    }
}

// Usage: We wrap the basic processor with auditing.
PaymentProcessor processor = new AuditingProcessor(
    new BasicProcessor(),
    new AuditService()
);
processor.process(new BigDecimal("99.95"));

The AuditingProcessor enhances the BasicProcessor without modifying it. You can stack decorators—imagine adding a RetryProcessor or a FraudCheckProcessor around it. It’s a very flexible way to combine behaviors.

In many systems, when something happens, other parts need to know. A user clicks a button, a file uploads, a price changes—subscribers need to react. This is the Observer Pattern. Modern applications often handle this asynchronously, and Java’s Reactive Streams provide a robust implementation.

Instead of managing lists of listeners manually, you can use a reactive Flux as an event stream.

public class TemperatureSensor {
    private final Sinks.Many<Double> temperatureSink = Sinks.many().multicast().onBackpressureBuffer();
    public final Flux<Double> readings = temperatureSink.asFlux();

    public void newReading(double celsius) {
        temperatureSink.tryEmitNext(celsius);
    }
}

// Different parts of the system can subscribe.
TemperatureSensor sensor = new TemperatureSensor();

// A display updates with every reading.
sensor.readings.subscribe(temp -> updateDashboard("Current: " + temp + "°C"));

// A thermostat checks for high temps.
sensor.readings
       .filter(temp -> temp > 30.0)
       .subscribe(temp -> triggerCoolingSystem());

// Simulate events
sensor.newReading(22.5);
sensor.newReading(31.2); // This will trigger the cooling system.

The Flux handles the hard parts: threading, backpressure (what happens if a subscriber is too slow), and completion. You just declare what should happen when an event arrives. This pattern is central to responsive, event-driven systems.

Frequently, you have a series of steps that must happen in a specific order, but the details of each step vary. The Template Method Pattern defines the skeleton of that process in a parent class or interface. With Java’s default methods in interfaces, we can implement this pattern very cleanly.

The interface defines the sequence of steps as a default method. The implementing classes fill in the blanks for each specific step.

public interface ReportGenerator {
    // This is the template method. It defines the algorithm.
    default String generateReport() {
        String data = fetchData();
        String processed = processData(data);
        return formatReport(processed);
    }

    // These are the steps subclasses must define.
    String fetchData();
    String processData(String rawData);

    // A helper method can be private to the interface.
    private String formatReport(String content) {
        return "=== REPORT ===\n" + content + "\n==============";
    }
}

public class SalesReport implements ReportGenerator {
    @Override
    public String fetchData() {
        return "Sales raw data from database";
    }

    @Override
    public String processData(String rawData) {
        return "Processed: " + rawData.toUpperCase();
    }
}

// The client just calls the template method.
ReportGenerator generator = new SalesReport();
String report = generator.generateReport(); // Fetches, processes, and formats.

The generateReport() method in the interface is the template. It calls the abstract methods fetchData() and processData(). Any class implementing ReportGenerator gets this complete process for free, only needing to provide the specific pieces. It ensures consistency across different report types.

Sometimes a request needs to go through a chain of checks or processors. Each handler in the chain looks at the request and decides: “Can I handle this? If not, I’ll pass it on.” This is the Chain of Responsibility. We can model this elegantly using a list of functions and Java’s Stream API.

You create a list of handlers. You then stream through them until one successfully handles the request.

import java.util.List;
import java.util.function.Predicate;

public class AuthorizationChain {
    private final List<Predicate<String>> handlers;

    public AuthorizationChain(List<Predicate<String>> handlers) {
        this.handlers = handlers;
    }

    public boolean authorize(String request) {
        return handlers.stream()
                       .anyMatch(handler -> handler.test(request));
    }
}

// Define your handlers as simple lambda expressions.
List<Predicate<String>> securityChecks = List.of(
    req -> { // Check for API key
        if (req.contains("key=abc123")) {
            System.out.println("Authenticated by API Key.");
            return true;
        }
        return false;
    },
    req -> { // Check for admin token
        if (req.contains("token=admin")) {
            System.out.println("Authenticated by Admin Token.");
            return true;
        }
        return false;
    },
    req -> { // Final fallback: deny access
        System.out.println("Access Denied.");
        return false;
    }
);

AuthorizationChain chain = new AuthorizationChain(securityChecks);
boolean granted = chain.authorize("request data key=abc123 more data");

The stream’s anyMatch will go through each handler in order. The first handler that returns true stops the chain, and the request is considered handled. This is perfect for request filtering, logging pipelines, or validation sequences.

Often, you want to turn an action into an object. This lets you store it, queue it, log it, or undo it. That’s the Command Pattern. In its simplest form, a Java Runnable or Consumer is already a command—it’s an action wrapped in an object.

You can build a simple task queue using this idea.

public class TaskManager {
    private final Queue<Runnable> pendingTasks = new LinkedList<>();

    public void addTask(Runnable task) {
        pendingTasks.add(task);
    }

    public void runTasks() {
        while (!pendingTasks.isEmpty()) {
            Runnable task = pendingTasks.poll();
            task.run(); // Execute the command
        }
    }
}

// Your commands are just lambda expressions.
TaskManager manager = new TaskManager();

manager.addTask(() -> System.out.println("Backing up database..."));
manager.addTask(() -> sendEmailAlert("[email protected]", "Report ready"));
manager.addTask(() -> cleanUpTempFiles());

// Later, execute all pending tasks.
manager.runTasks();

Each () -> ... lambda is a command object. The TaskManager doesn’t need to know what the command does; it just knows it can run() it. For more complex needs, like commands that can be undone, you would create a full class with execute() and undo() methods, but for many cases, a lambda is perfectly sufficient.

Finally, let’s consider a system with different types of objects, like shapes in a geometry app. You need to perform various operations on them: calculate area, render to screen, export to XML. If you keep adding methods to the shape classes for each new operation, they become bloated. The Visitor Pattern lets you separate the operation from the objects.

You define a visitor interface with a method for each type of object. Then, each object accepts a visitor and lets it perform the operation.

Modern Java’s sealed classes make this pattern safer and more explicit. A sealed interface tells the compiler exactly which shapes exist.

public sealed interface Shape permits Circle, Square {
    <T> T visit(ShapeVisitor<T> visitor);
}

public record Circle(double radius) implements Shape {
    @Override
    public <T> T visit(ShapeVisitor<T> visitor) {
        return visitor.handle(this); // "this" is a Circle
    }
}

public record Square(double side) implements Shape {
    @Override
    public <T> T visit(ShapeVisitor<T> visitor) {
        return visitor.handle(this); // "this" is a Square
    }
}

// The visitor interface knows about all concrete shapes.
public interface ShapeVisitor<T> {
    T handle(Circle circle);
    T handle(Square square);
}

// A concrete visitor: Area Calculator
public class AreaCalculator implements ShapeVisitor<Double> {
    @Override
    public Double handle(Circle circle) {
        return Math.PI * circle.radius() * circle.radius();
    }

    @Override
    public Double handle(Square square) {
        return square.side() * square.side();
    }
}

// A concrete visitor: JSON Exporter
public class JsonExporter implements ShapeVisitor<String> {
    @Override
    public String handle(Circle circle) {
        return String.format("{\"type\": \"circle\", \"radius\": %.2f}", circle.radius());
    }

    @Override
    public String handle(Square square) {
        return String.format("{\"type\": \"square\", \"side\": %.2f}", square.side());
    }
}

// Usage
Shape circle = new Circle(5.0);
Shape square = new Square(4.0);

AreaCalculator calc = new AreaCalculator();
System.out.println("Circle area: " + circle.visit(calc));

JsonExporter exporter = new JsonExporter();
System.out.println("Square as JSON: " + square.visit(exporter));

The power here is twofold. First, adding a new operation like JsonExporter doesn’t require changing the Circle or Square records at all. Second, because Shape is sealed, the compiler knows all its possible types. If you later add a Triangle, the compiler will force you to update the ShapeVisitor interface to handle it, preventing runtime errors. This makes the pattern much more reliable.

These patterns are not rules to be followed blindly. They are tools. When you see a code problem that feels familiar—like managing object creation, adding flexible behavior, or handling events—remember these tools. Modern Java, with its lambdas, records, sealed classes, and streams, lets you apply these patterns with less code and more clarity. The goal is always to write software that is easier to understand, change, and maintain over time. Start by recognizing the problem, then see if one of these proven solutions fits. You’ll often find it leads to cleaner, more communicative code.