Design Patterns on Aamer Paul

Strategy Pattern in Action

Sat, 02 Aug 2025 08:53:20 +0530

Strategy Pattern is a behavioral design pattern that enables selecting an algorithm’s behavior at runtime.

It’s widely used and very flexible, perfect for cases where you want to avoid complex if-else or switch statements.

Use cases

You want to replace conditionals (if-else or switch) with polymorphism.
You need to switch behavior at runtime or make it configurable. Example: User selecting payment option
You want to define multiple ways of doing something (e.g., sorting, compression, payment).

Core Concepts

The pattern consists of three main components:

Builder Design Pattern

Mon, 28 Jul 2025 18:30:20 +0530

The Builder Design Pattern is a creational design pattern that lets you construct complex objects step by step. Using Builder pattern you can use same construction process to can create different representations.

Use case

Use the Builder Pattern when:

An object has many optional fields or configurations.
You want to avoid constructor telescoping (i.e., too many overloaded constructors).
You need to create immutable objects step by step.

public class User {
    private String firstName;
    private String lastName;
    private int age;
    private String email;
    private String phone;

    public User(String firstName, String lastName) { ... }
    public User(String firstName, String lastName, int age) { ... }
    public User(String firstName, String lastName, int age, String email) { ... }

    // ...
}

In above example, you can see User class is hard to maintain and read.

Factory and Abstract Factory Design Pattern

Sun, 27 Jul 2025 10:51:59 +0530

Factory Design Pattern

Factory Pattern is creational pattern that delegate the instantiation of objects to a separate method or class.

The Factory design pattern provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that’ll be created. This pattern helps to decouple the client code from the concrete classes it needs to instantiate.

Core Components

The Factory pattern has three main components:

Singleton Design Pattern

Sat, 26 Jul 2025 11:02:04 +0530

Singleton design pattern is a creational design pattern that restricts instantiation of a class ensuring class has only one instance and provide a global point of access to it.

Common Implementations

Lazy Initialization: ensures instance is created only when it is first requested.
Eager Initialization: instance is created when the class is loaded.
Thread-Safe Implementations: ensures the singleton works correctly in multi-threaded environments, such as using synchronized methods or double-checked locking. (though double-checked locking has nuances and is sometimes considered an anti-pattern in modern Java)

Use Cases

Logging
Configuration settings
Thread pools
Caches
Device drivers

Examples

Eager initialization

public class Singleton {
    private static final Singleton instance = new Singleton();

    private EagerInitializedSingleton(){}

    public static Singleton getInstance() {
        return instance;
    }
}

Useful if your singleton class is not using a lot of resources.

Using `synchronized` method (Lazy initialization)

public class Singleton {

    // Volatile ensures visibility and prevents reordering
    private static volatile Singleton instance;

    private Singleton() {
    }

    // Thread-safe with method-level synchronization
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

    public void example() {
        System.out.println("Hello from Singleton!, (using synchronized method)");
    }
}

Lazily initialization the instance.
synchronized ensures that only one thread can enter the method at a time.
It ensures lazy initialization — Singleton instance is created only when needed.
Performance overhead: Every call to getInstance() acquires a lock, even after the instance has been initialized. This is unnecessary and can be expensive under heavy load.

Double-Checked Locking (Lazy initialization)

public class Singleton {

    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) { // <- Double-check
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    public void example() {
        System.out.println("Hello from Singleton!, (double-check)");
    }

}

Lazily initialization the instance.
double check aims to minimize the overhead of synchronization.
Complex

Bill Pugh (Inner Class) - Recommended Approach

public class Singleton {
    private Singleton() {
        // Prevent reflection attack
        if (SingletonHelper.INSTANCE != null) {
            throw new RuntimeException("Use getInstance() method to get the single instance of this class");
        }
    }

    private static class SingletonHelper {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonHelper.INSTANCE;
    }

    public void example() {
        System.out.println("Hello from Singleton!, (Bill Pugh)");
    }
}

Static inner helper class is loaded only when getInstance() is called.
Class loading is thread-safe.
No need for synchronized, and lazy initialization is achieved.

Drawbacks

Despite its utility, the Singleton pattern is sometimes criticized as an anti-pattern because it can: