Design Patterns in Java

Singleton Pattern

The Singleton pattern ensures that a class has only one instance and provides a global access point to that object. In Java, this is achieved by making the constructor private, creating a static instance of the class, and providing a public static getter method. This is essential for resource management, such as configuration managers or database connection pools where multiple instances would lead to inconsistent states or memory overhead. By controlling the instantiation, the system prevents unauthorized duplication. When designing systems, use this pattern sparingly as it introduces global state, which can make testing more difficult. However, its benefit in scenarios like logging, where a single central point of entry is required to synchronize writes to a file, is unparalleled. You must ensure thread safety by using synchronized access or static initialization to prevent race conditions during the initial creation of the instance by multiple threads simultaneously.

public class ConfigurationManager {
    // Static instance created during class loading
    private static final ConfigurationManager INSTANCE = new ConfigurationManager();

    private ConfigurationManager() {}

    public static ConfigurationManager getInstance() {
        return INSTANCE;
    }
}

Factory Method Pattern

The Factory Method pattern defines an interface for creating objects but delegates the specific instantiation process to subclasses. This promotes loose coupling because the client code interacts with an abstraction rather than concrete classes. By isolating object creation, you make the application more resilient to changes; if the underlying implementation of a product changes, you only modify the factory, not the high-level business logic. This is particularly useful in framework development or when an application needs to support multiple variants of a service, such as different types of document exporters. The reasoning here is based on the Dependency Inversion Principle, which encourages relying on interfaces. When you implement this, consider that it adds an extra layer of complexity, but the trade-off is a flexible design where adding a new type simply involves creating a new subclass and a corresponding factory method, adhering to the Open/Closed Principle.

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

public class CreditCardProcessor implements PaymentProcessor {
    public void process(double amount) { /* Logic for card */ }
}

public class PaymentFactory {
    public static PaymentProcessor getProcessor(String type) {
        if ("card".equals(type)) return new CreditCardProcessor();
        return null;
    }
}

Builder Pattern

The Builder pattern is designed to solve the problem of constructors with too many parameters, often called the 'telescoping constructor' antipattern. When an object requires several optional fields, creating multiple constructor variants leads to confusing and error-prone code. A Builder provides a fluent API, allowing the developer to chain method calls to set specific parameters before calling a final build method. This separation of concerns ensures that the object is always created in a valid, immutable state. It is highly beneficial for complex data objects that require non-trivial validation logic during initialization. By separating the construction process from the representation, you can construct different complex objects using the same building process. This approach is superior because it makes the calling code readable and prevents the creation of partially initialized objects that could lead to runtime exceptions if fields were left at their default null values.

public class User {
    private final String name; // immutable
    private User(Builder b) { this.name = b.name; }
    public static class Builder {
        private String name;
        public Builder name(String n) { this.name = n; return this; }
        public User build() { return new User(this); }
    }
}

Observer Pattern

The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. This is a behavioral pattern that enables loose coupling between the subject and its observers, allowing them to vary independently. The subject does not need to know the specific types of the observers, only that they implement a specific notification interface. This is the foundation of event-driven architectures in Java, such as GUI listeners or messaging systems. By using this pattern, you avoid hard-coding dependencies between systems that need to communicate updates, thus making your codebase much easier to extend. If a new observer needs to monitor the subject, it simply registers itself without modifying the subject's code. This modularity ensures that the system remains maintainable even as new requirements regarding real-time synchronization or status tracking are introduced over time.

import java.util.*;
public class NewsAgency {
    private List<Observer> observers = new ArrayList<>();
    public void addObserver(Observer o) { observers.add(o); }
    public void notifyObservers(String msg) {
        for(Observer o : observers) o.update(msg);
    }
}

Strategy Pattern

The Strategy pattern allows you to define a family of algorithms, encapsulate each one, and make them interchangeable at runtime. Instead of using complex conditional statements like 'if-else' or 'switch' to determine behavior, you delegate the execution to a strategy object. This design strictly follows the Open/Closed Principle because you can introduce new strategies without modifying the client code that executes them. It is useful in any scenario involving alternative logic paths, such as different tax calculation rules, sorting algorithms, or file compression methods. By treating algorithms as objects, you improve testability, as each strategy can be verified in isolation. The reasoning is to favor composition over inheritance; by holding a reference to a strategy interface, the context object can switch its behavior dynamically based on user input or state. This results in cleaner, more modular code that avoids the bloat of massive, multi-purpose classes that are difficult to debug or maintain.

public interface SortStrategy { void sort(int[] arr); }

public class QuickSort implements SortStrategy {
    public void sort(int[] arr) { /* Logic here */ }
}

public class Sorter {
    private SortStrategy strategy;
    public void setStrategy(SortStrategy s) { this.strategy = s; }
    public void execute(int[] arr) { strategy.sort(arr); }
}

Interview questions

All java interview questions →

Check yourself

Take the full java quiz →