Design Pattern

Welcome To Design Pattern Blog By Nitesh Synergy

✅ What is a Design Pattern?

A design pattern is a proven, reusable solution to a common problem in software design. It is not a complete code, but a template or guideline on how to solve specific design issues in object-oriented software.

Think of design patterns like blueprints—software architects use them to build robust, maintainable, and scalable applications.

🎯 Why Are Design Patterns Needed?

Reusability – Save time by using tried-and-tested solutions.
Scalability – Help build flexible, easily extendable code.
Maintainability – Code becomes easier to understand and update.
Standardization – Brings a common vocabulary for developers.
Avoid Re-inventing the Wheel – Use known solutions for known problems.

🧱 Types of Design Patterns

Design patterns are broadly classified into 3 main categories:

1. Creational Patterns (Object creation)

Used when object creation is complex or needs to be controlled.

Pattern Name	Purpose
Singleton	Only one instance of a class.
Factory Method	Create objects without exposing the exact class.
Abstract Factory	Factory of related factories.
Builder	Step-by-step object creation.
Prototype	Clone existing objects.

Singleton Pattern

✅ What is Singleton Pattern?

Singleton is a creational design pattern that ensures:

Only one instance of a class exists throughout the application.
Provides a global point of access to that instance.

✅ Why Singleton is Important?

Resource Control: Controls access to resources like DB connections, configuration files, or loggers.
Memory Efficiency: Avoids creation of multiple objects of the same class unnecessarily.
Consistency: Ensures consistent state/data across the system.

✅ When to Use Singleton? (Use Cases)

Use Singleton when:

Single Configuration Across App
- E.g., App-wide configuration manager or settings file.
Database Connection Pool
- Only one connection manager instance to handle all DB operations.
Logging
- Centralized logger instance to log from any part of the app.
Caching
- Central cache store used throughout application.
Thread Pool
- Single pool used by multiple threads.

✅ Real-Time Project Example

🔹 Project: E-commerce Application

Singleton Use:
- A Logger class logs order activity, errors, payments.
- DatabaseConnector class manages connections to the MySQL DB.
- AppConfig class loads settings like tax %, currencies, and uses it across services.

❌ When Not to Use Singleton

Avoid Singleton when:

Unit Testing Needed
- Singleton hides dependencies, making mocking hard.
Multi-threading if not handled properly
- Poor implementation can lead to race conditions.
Global State is a Problem
- Leads to tight coupling between classes.
Requires Multiple Instances
- E.g., Different connections for different databases.

Rules For Singleton Pattern:

🔒 1. Private Constructor

Ensure the class constructor is private to prevent instantiation from outside the class.

📦 2. Static Instance Variable

Create a static (ideally final) variable to hold the single instance of the class.

🌍 3. Global Access Point

Provide a public static method or property that returns the same instance every time it's called.

🧵 4. Thread Safety

In multithreaded environments, ensure that the instance creation logic is thread-safe to avoid multiple instances being created.

❌ 5. Prevent Cloning

Override the cloning behavior to avoid duplication of the singleton object via clone().

🔐 6. Serialization Safety

Implement mechanisms (like readResolve() in Java) to prevent deserialization from creating a new instance.

🪞 7. Reflection Safety

Add checks inside the constructor to throw an exception if an instance already exists, thus protecting against reflection-based instantiation.

⚡ 8. Static Block for Eager Initialization

Use a static block to eagerly initialize the singleton and include logic to prevent reflection-based violations if needed.

🛡️ 9. Use of `final` Keyword

Mark the instance variable as final to ensure immutability and prevent reassignment after initialization.

📌 Guidelines for Using Singleton

Use Only When Necessary: Singleton introduces global state — use it only when a single instance is essential (e.g., config, logging).
Avoid Overuse: Overuse leads to tight coupling and makes testing harder.
Ensure Thread Safety: Always ensure thread-safe implementation in concurrent environments.
Testing Considerations: Mock singleton objects during unit testing to isolate dependencies.
Lazy vs Eager Initialization:
- Use lazy initialization when the object is heavy and not always needed.
- Use eager initialization when the object is lightweight or always needed.

✅Ways To Achieve Singleton Pattern:

Sol-1:
Basic Singleton Implementation (Eager Initialization):

Advantages: Simple, thread-safe without additional synchronization.
Disadvantages: Instance is created at class loading, even if it’s never used.

public class Singleton {
   private static final Singleton INSTANCE = new Singleton(); // Static instance
   
   private Singleton() {
       // Private constructor
   }
   
   public static Singleton getInstance() {
       return INSTANCE; // Global access point
   }
}

Sol-2:

Lazy Initialization

Advantages: Instance is created only when required.
Disadvantages: Not thread-safe.

public class Singleton {
   private static Singleton instance;
   
   private Singleton() {
       // Private constructor
   }
   
   public static Singleton getInstance() {
       if (instance == null) {
           instance = new Singleton();
       }
       return instance;
   }
}

Sol-3:

Thread-Safe Singleton (Synchronized Method)

advantages: Thread-safe.
Disadvantages: Performance overhead due to synchronized method.

public class Singleton {
   private static Singleton instance;
   
   private Singleton() {
       // Private constructor
   }
   
   public static synchronized Singleton getInstance() {
       if (instance == null) {
           instance = new Singleton();
       }
       return instance;
   }
}

Sol-4:

Thread-Safe Singleton (Double-Checked Locking)

Advantages: Efficient, avoids unnecessary synchronization after initialization.
Disadvantages: Requires understanding of volatile keyword.

→ For all keywords -https://www.niteshsynergy.com/java

public class Singleton {
   private static volatile Singleton instance;
   
   private Singleton() {
       // Private constructor
   }
   
   public static Singleton getInstance() {
       if (instance == null) {
           synchronized (Singleton.class) {
               if (instance == null) {
                   instance = new Singleton();
               }
           }
       }
       return instance;
   }
}

Sol-5:

Reflection Safety:

public class Singleton {
   private static Singleton instance;
   private Singleton() {
       // Prevent Reflection from creating another instance
       if (instance != null) {
           throw new IllegalStateException("Singleton instance already created!");
       }
   }
   public static Singleton getInstance() {
       if (instance == null) {
           synchronized (Singleton.class) {
               if (instance == null) {
                   instance = new Singleton();
               }
           }
       }
       return instance;
   }
}

Sol-6:

Singleton with Enum (Best Practice):

// Singleton Enum for Logging Utility
public enum Logger {
   INSTANCE;
   // Method to log messages
   public void log(String message) {
       System.out.println("LOG: " + message);
   }
   // Method to log errors
   public void logError(String errorMessage) {
       System.err.println("ERROR: " + errorMessage);
   }
}
public class UserService {
   // Some user-related logic
   public void createUser(String username) {
       // Log an informational message
       Logger.INSTANCE.log("User creation started for: " + username);
       
       try {
           // Simulating user creation logic
           if (username == null || username.isEmpty()) {
               throw new IllegalArgumentException("Username cannot be null or empty");
           }
           // Simulate user created
           Logger.INSTANCE.log("User created successfully: " + username);
       } catch (Exception e) {
           // Log the error using Singleton Logger
           Logger.INSTANCE.logError("Error creating user: " + e.getMessage());
       }
   }
}

Sol-7:

Preventing Cloning via the clone() Method:

public class Singleton {
   private static Singleton instance;
   private Singleton() {
       if (instance != null) {
           throw new IllegalStateException("Singleton instance already created!");
       }
   }
   public static Singleton getInstance() {
       if (instance == null) {
           synchronized (Singleton.class) {
               if (instance == null) {
                   instance = new Singleton();
               }
           }
       }
       return instance;
   }
   @Override
   public Object clone() {
       throw new CloneNotSupportedException("Cloning of Singleton is not allowed!");
   }
}

Sol-8:

Preventing Serialization Attack:

public class Singleton implements Serializable {
   private static final long serialVersionUID = 1L;
   private static Singleton instance;
   private Singleton() {
       if (instance != null) {
           throw new IllegalStateException("Singleton instance already created!");
       }
   }
   public static Singleton getInstance() {
       if (instance == null) {
           synchronized (Singleton.class) {
               if (instance == null) {
                   instance = new Singleton();
               }
           }
       }
       return instance;
   }
   // Ensure Singleton instance is preserved during serialization/deserialization
   protected Object readResolve() {
       return instance;
   }
}

Sol-9:

Using a Static Block (Eager Initialization with Reflection Safety):

public class Singleton {
   private static final Singleton instance;
   static {
       try {
           instance = new Singleton();
       } catch (Exception e) {
           throw new IllegalStateException("Singleton instance already created!");
       }
   }
   private Singleton() {
       // Prevent Reflection from creating another instance
       if (instance != null) {
           throw new IllegalStateException("Singleton instance already created!");
       }
   }
   public static Singleton getInstance() {
       return instance;
   }
}

Sol-10:

Use of final Keyword:

public class Singleton {
   private static final Singleton instance;
   static {
       instance = new Singleton();
   }
   private Singleton() {
       // Prevent Reflection from creating another instance
       if (instance != null) {
           throw new IllegalStateException("Singleton instance already created!");
       }
   }
   public static Singleton getInstance() {
       return instance;
   }
}

→There are many other option to create Singleton class.

Below code for Singleton breaking ways:

//Code to break: 1. Reflection
class BreakWithReflection {
   public static void breakWithReflection() {
       try {
           Singleton instance1 = Singleton.getInstance();
           Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
           constructor.setAccessible(true); // Bypass private access
           Singleton instance2 = constructor.newInstance();
           System.out.println(" From breakWithReflection");
           System.out.println(instance1.hashCode());
           System.out.println(instance2.hashCode());
       } catch (Exception e) {
           e.printStackTrace();
       }
   }
}

//2. Serialization/Deserialization way break
class BreakWithSerialization {
   public static void breakWithSerialization() throws Exception {
       Singleton instance1 = Singleton.getInstance();
       // Serialize instance
       ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("singleton.ser"));
       out.writeObject(instance1);
       out.close();
       // Deserialize instance
       ObjectInputStream in = new ObjectInputStream(new FileInputStream("singleton.ser"));
       Singleton instance2 = (Singleton) in.readObject();
       in.close();
       System.out.println(" From breakWithSerialization");
       System.out.println(instance1.hashCode());
       System.out.println(instance2.hashCode());
   }
}

// 3. Cloning way break
class BreakWithCloning {
   public static void breakWithCloning() throws CloneNotSupportedException {
       Singleton instance1 = Singleton.getInstance();
       Singleton instance2 = (Singleton) instance1.clone(); // If clone() is accessible
       System.out.println(" From breakWithCloning");
       System.out.println(instance1.hashCode());
       System.out.println(instance2.hashCode());
   }
}

// 4. Multithreading (Race Condition)
class BreakWithMultithreading {
   public static void breakWithMultithreading() {
       Runnable task = () -> {
           Singleton instance = Singleton.getInstance();
           System.out.println(instance.hashCode());
       };
       Thread thread1 = new Thread(task);
       Thread thread2 = new Thread(task);
       System.out.println(" From BreakWithMultithreading");
       thread1.start();
       thread2.start();
   }
}

//5. Garbage Collection
class BreakWithGarbageCollection {
   public static void breakWithGarbageCollection() {
       Singleton instance = Singleton.getInstance();
       WeakReference<Singleton> weakRef = new WeakReference<>(instance);
       instance = null; // Nullify the strong reference
       System.gc(); // Force garbage collection
       System.out.println(" From breakWithGarbageCollection");
       Singleton newInstance = Singleton.getInstance();
       System.out.println(weakRef.get() == newInstance); // False if GC removed the weak reference
   }
}

//6. Subclassing
class BreakWithSubclassing {
   public static void breakWithSubclassing() {
    //   Singleton subclassInstance = new Singleton() {}; // Anonymous subclass
   //    System.out.println(subclassInstance.hashCode());
   }
}

class Singleton{
   private static Singleton instance;
   private Singleton(){
   }
   public static Singleton getInstance() {
       if (instance == null) {
           instance = new Singleton();
       }
       return instance;
   }
   
   // // If clone() is accessible, // 3. Cloning way break
   @Override
   public Object clone() throws CloneNotSupportedException {
       return super.clone();
   }
   
   public void showMessage() {
       System.out.println("Singleton Instance");
   }
}

package com.niteshsynergy.designPattern.CreationalDesign;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.lang.ref.WeakReference;
import java.lang.reflect.Constructor;
public class Demo1 {
   public static void main(String[] args) throws Exception {
     /*  Singleton s1 = Singleton.getInstance();
       System.out.println(s1.hashCode());
       Singleton s2 = Singleton.getInstance();
       System.out.println(s2.hashCode());
       */
       BreakWithReflection.breakWithReflection();
       BreakWithSerialization.breakWithSerialization();
       BreakWithCloning.breakWithCloning();
       BreakWithMultithreading.breakWithMultithreading();
       BreakWithGarbageCollection.breakWithGarbageCollection();
       BreakWithSubclassing.breakWithSubclassing();
   }
   //Prevention Strategies:
   //Prevent Reflection: Add a check in the private constructor.
  /* private Singleton() {
       if (instance != null) {
           throw new IllegalStateException("Instance already created!");
       }
   }*/
   //Serialization Protection: Implement readResolve().
 /*  protected Object readResolve() {
       return instance;
   }*/
   //Prevent Cloning: Override clone() and throw an exception.
   //java
   //Copy code
   @Override
   protected Object clone() throws CloneNotSupportedException {
       throw new CloneNotSupportedException("Cannot clone singleton");
   }
   //Thread-Safe Initialization: Use Bill Pugh Singleton or Double-Checked Locking.
   //Final Class: Declare the class as final to prevent subclassing.

}

✅ Real-World Use Cases of Singleton Class

🏦 1. Banking System Use Case

Use Case: Centralized Transaction Manager

In a banking application, all deposit, withdrawal, and transfer operations must go through a single TransactionManager to maintain consistency.
This manager must be a Singleton to ensure that all operations are logged and validated through one point—preventing data inconsistencies in concurrent environments.

🔹 Why Singleton?

Ensures one version of the transaction flow logic
Prevents double processing or conflicting operations

🔗 2. JDBC Connection Pool (Database Access Layer)

Use Case: DatabaseConnectionManager Singleton

In any Java app (or backend API), database operations use JDBC.
A DatabaseConnectionManager class can be Singleton so it maintains a single connection pool reused by all DAOs (Data Access Objects).

🔹 Why Singleton?

Saves system resources
Manages connection limits efficiently
Reduces overhead of repeatedly opening/closing connections

🎮 3. Gaming Application

Use Case: GameSettings or GameEngine Singleton

In a game, GameSettings (like resolution, sound level, difficulty level) are set once and used across multiple levels/screens.
Or the GameEngine managing game loop, rendering, and physics should only be one across the app.

🔹 Why Singleton?

Consistent behavior across game scenes
Prevents re-initializing core game logic
Shares resources like physics engine, AI logic across levels

🤖 4. AI/ChatGPT-Based App Use Case

Use Case: AIModelManager or APIClientManager

Imagine building an AI-based tool like ChatGPT:

You integrate OpenAI or a custom LLM into your system.
A Singleton class (e.g., AIModelManager) ensures the prompt formatting, token handling, or rate-limit logic is handled centrally.
Or a Singleton APIClient manages the HTTP connection, headers, and authorization tokens.

🔹 Why Singleton?

Avoids multiple heavy model initializations
Centralized control over API call logic
Manages rate limits, retries, and tokens from one place
Reduces latency by reusing configuration and headers

📌 Summary Table

Domain	Singleton Class Example	Purpose
Banking	TransactionManager	Maintain consistency and log transactions
JDBC/Backend	DatabaseConnectionManager	Reuse DB connections, optimize resource usage
Gaming	GameEngine / GameSettings	Global settings and logic across game screens
AI Tools	AIModelManager / APIClient	Centralized model config and API management

→ Perfect Singleton:GameEngine Singleton (Central Control for a Game App)

✅ `GameEngineSingleton.java` — Perfect Singleton for Game Engine

package com.niteshsynergy.designPattern.CreationalDesign;

import java.io.Serializable;

public final class GameEngineSingleton implements Serializable, Cloneable {

private static class GameEngineHelper {
private static final GameEngineSingleton INSTANCE = new GameEngineSingleton();
}

private GameEngineSingleton() {
if (GameEngineHelper.INSTANCE != null) {
throw new IllegalStateException("Instance already created!");
}
}

public static GameEngineSingleton getInstance() {
return GameEngineHelper.INSTANCE;
}

@Override
protected Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException("Cloning not allowed for GameEngineSingleton");
}

protected Object readResolve() {
return getInstance();
}

// Game-related logic
public void startGame() {
System.out.println("Game started...");
}

public void stopGame() {
System.out.println("Game stopped...");
}

public void updateGameState() {
System.out.println("Game state updated.");
}
}

✅ `GameEngineClient.java` — Client Code to Use Singleton

package com.niteshsynergy.designPattern.CreationalDesign;

public class GameEngineClient {
public static void main(String[] args) {
GameEngineSingleton engine1 = GameEngineSingleton.getInstance();
GameEngineSingleton engine2 = GameEngineSingleton.getInstance();

engine1.startGame();
engine2.updateGameState();

System.out.println(engine1 == engine2); // true — proves Singleton
}
}

Why Singleton is Ideal Here?

Reason	Explanation
💾 Resource Management	Avoids multiple heavy initializations of rendering or sound engines.
🔄 Global State	Game progress, score, and events stay consistent across game screens.
🎮 Central Control	Game loop and state transitions are managed centrally.
✅ Safety	Protected from cloning, reflection, and serialization issues.

→ Next

Factory Pattern

✅ What is Factory Pattern?

The Factory Pattern is a creational design pattern that provides an interface or method for creating objects without exposing the creation logic to the client.

Instead, the client uses a method to get instances based on a type, name, or key.

✅ When to Use Factory Pattern?

When the class you need to instantiate depends on input or context.
When you want to avoid tight coupling between the code using the objects and the object types.
When the object creation logic is complex, repetitive, or conditional.

✅ Why Use It?

Centralized Object Creation: Keeps creation logic in one place.
Encapsulation: Hides complexities of instantiation.
Polymorphism: Returns objects of the same interface but different implementations.
Maintainability: New types can be added with minimal code changes (Open/Closed Principle).

❌ Why NOT Use It?

Overkill for Simple Scenarios: If object creation is trivial, Factory adds unnecessary abstraction.
Too Many Classes: Each object type might require a new class, increasing complexity.

🎯 Use Cases

UI Components (Buttons, Windows, Themes)
Payment Gateways (CreditCard, PayPal, UPI)
Notification Systems (Email, SMS, Push)
Gaming Characters (Player, Enemy, NPCs)
Vehicle Production (Car, Bike, Truck)

Use Case: Drawing different shapes

Client asks: "Give me a shape: circle, square, or rectangle"

Factory returns appropriate object and client just calls draw().

Use Case: Create different in-game characters dynamically (Player, Enemy, PowerUp, Boss)

→ Common Interface:

public interface GameCharacter {
void action();
}

Implementations:

public class Player implements GameCharacter {
public void action() {
System.out.println("Player attacks with sword.");
}
}

public class Enemy implements GameCharacter {
public void action() {
System.out.println("Enemy shoots arrows.");
}
}

public class PowerUp implements GameCharacter {
public void action() {
System.out.println("PowerUp grants extra life.");
}
}

public class Boss implements GameCharacter {
public void action() {
System.out.println("Boss unleashes special power.");
}
}

Factory Class :

public class GameCharacterFactory {
public static GameCharacter createCharacter(String type) {
return switch (type.toLowerCase()) {
case "player" -> new Player();
case "enemy" -> new Enemy();
case "powerup" -> new PowerUp();
case "boss" -> new Boss();
default -> throw new IllegalArgumentException("Unknown character type");
};
}
}

Client Code:

public class GameApp {
public static void main(String[] args) {
GameCharacter player = GameCharacterFactory.createCharacter("player");
GameCharacter enemy = GameCharacterFactory.createCharacter("enemy");
GameCharacter boss = GameCharacterFactory.createCharacter("boss");

player.action();
enemy.action();
boss.action();
}
}

✅Why Factory is Ideal Here

Aspect	Without Factory	With Factory Pattern
Object Creation	Scattered in multiple places	Centralized in one factory class
Adding New Character	Modify client code	Just extend factory + new class
Polymorphism	Manually handled or inconsistent	Handled elegantly via interface
Flexibility	Low — tightly coupled	High — loosely coupled
Testing and Mocking	Harder due to direct instantiation	Easy to mock via interface
Open/Closed Principle	Violated when modifying logic	Fully respected

✅ Factory Pattern is essential when your app needs:

Flexible and dynamic object creation
Better maintainability
Polymorphic behavior via interfaces
Centralized control over creation logic

Prototype Pattern

Prototype Pattern lets you create objects by cloning an existing object (the prototype), instead of instantiating a new one using new.

Use Case

Games: Creating characters, weapons, or other entities with shared configurations.
Document Processing: Cloning complex document templates.
GUI Applications: Reproducing UI elements like buttons and windows.
Simulations: Copying complex objects like vehicles or terrain.

Step 1: Common Interface
public interface Prototype extends Cloneable {
   Prototype clone();
}

Step 2: Concrete Prototype Classes
public class Circle implements Prototype {
    private int radius;

    public Circle(int radius) {
        this.radius = radius;
    }

    public void setRadius(int radius) {
        this.radius = radius;
    }

    @Override
    public Prototype clone() {
        return new Circle(this.radius);
    }

    @Override
    public String toString() {
        return "Circle with radius " + radius;
    }
}

public class Rectangle implements Prototype {
    private int width;
    private int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    public void setDimensions(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public Prototype clone() {
        return new Rectangle(this.width, this.height);
    }

    @Override
    public String toString() {
        return "Rectangle [width=" + width + ", height=" + height + "]";
    }
}


Step 3: Prototype Registry


import java.util.HashMap;
import java.util.Map;

public class PrototypeRegistry {
    private Map<String, Prototype> prototypes = new HashMap<>();

    public void addPrototype(String key, Prototype prototype) {
        prototypes.put(key, prototype);
    }

    public Prototype getPrototype(String key) {
        Prototype prototype = prototypes.get(key);
        return prototype != null ? prototype.clone() : null;
    }
}

Step 4: Client Code

public class Main {
    public static void main(String[] args) {
        // Create prototype objects
        Circle circlePrototype = new Circle(10);
        Rectangle rectanglePrototype = new Rectangle(20, 30);

        // Register prototypes
        PrototypeRegistry registry = new PrototypeRegistry();
        registry.addPrototype("circle", circlePrototype);
        registry.addPrototype("rectangle", rectanglePrototype);

        // Create new objects by cloning
        Circle clonedCircle = (Circle) registry.getPrototype("circle");
        Rectangle clonedRectangle = (Rectangle) registry.getPrototype("rectangle");

        // Modify clones
        clonedCircle.setRadius(15);
        clonedRectangle.setDimensions(40, 50);

        // Print results
        System.out.println(clonedCircle); // Circle with radius 15
        System.out.println(clonedRectangle); // Rectangle [width=40, height=50]
    }
}

Gaming Code: Cloning Game Entities

A game has various entities (e.g., players, enemies, and weapons) with complex initialization logic. Instead of recreating entities, we clone pre-configured prototypes.

Step 1: Common Interface

public interface GameEntity extends Cloneable {
   GameEntity clone();
   void render();
}

Step 2: Concrete Entity Classes
public class Player implements GameEntity {
    private String name;
    private int health;
    private int attackPower;

    public Player(String name, int health, int attackPower) {
        this.name = name;
        this.health = health;
        this.attackPower = attackPower;
    }

    public void setAttributes(String name, int health, int attackPower) {
        this.name = name;
        this.health = health;
        this.attackPower = attackPower;
    }

    @Override
    public GameEntity clone() {
        return new Player(this.name, this.health, this.attackPower);
    }

    @Override
    public void render() {
        System.out.println("Player: " + name + ", Health: " + health + ", Attack Power: " + attackPower);
    }
}

public class Enemy implements GameEntity {
    private String type;
    private int health;

    public Enemy(String type, int health) {
        this.type = type;
        this.health = health;
    }

    public void setAttributes(String type, int health) {
        this.type = type;
        this.health = health;
    }

    @Override
    public GameEntity clone() {
        return new Enemy(this.type, this.health);
    }

    @Override
    public void render() {
        System.out.println("Enemy: " + type + ", Health: " + health);
    }
}

Step 3: Prototype Registry

import java.util.HashMap;
import java.util.Map;

public class GameEntityRegistry {
    private Map<String, GameEntity> prototypes = new HashMap<>();

    public void addPrototype(String key, GameEntity entity) {
        prototypes.put(key, entity);
    }

    public GameEntity getPrototype(String key) {
        return prototypes.get(key).clone();
    }
}

Step 4: Client Code
public class GameMain {
    public static void main(String[] args) {
        // Create prototypes
        Player playerPrototype = new Player("Default Player", 100, 50);
        Enemy enemyPrototype = new Enemy("Zombie", 75);

        // Register prototypes
        GameEntityRegistry registry = new GameEntityRegistry();
        registry.addPrototype("player", playerPrototype);
        registry.addPrototype("zombie", enemyPrototype);

        // Clone and modify entities
        Player player1 = (Player) registry.getPrototype("player");
        player1.setAttributes("Player1", 120, 60);

        Enemy zombie1 = (Enemy) registry.getPrototype("zombie");
        zombie1.setAttributes("Zombie1", 80);

        // Render entities
        player1.render();
        zombie1.render();
    }
}

Output Example

Player: Player1, Health: 120, Attack Power: 60
Enemy: Zombie1, Health: 80

Builder Pattern

Builder Pattern lets you create a complex object in parts, using simple steps — and you control how it’s built.

✅ Why is Builder Pattern needed?

✅ When an object has lots of optional fields or configurations
✅ When object construction is too complex to handle in a single constructor
✅ To make code clean, readable, and maintainable
✅ To create different variations of the same object easily

🔍 Real-life Analogy:

Imagine building a burger at a restaurant:
You choose bun, cheese, veggies, sauces, etc.
The Burger Builder prepares it step-by-step.
You get the final burger your way 🍔

Use Case

Constructing objects with many optional parameters, such as HTTP requests.
Building vehicles in games, e.g., tanks, cars, and planes.
Assembling complex entities in RPG games, e.g., player profiles or NPCs.

Step 1: Product Class

public class House {
   private String foundation;
   private String structure;
   private String roof;
   public void setFoundation(String foundation) {
       this.foundation = foundation;
   }
   public void setStructure(String structure) {
       this.structure = structure;
   }
   public void setRoof(String roof) {
       this.roof = roof;
   }
   @Override
   public String toString() {
       return "House [Foundation=" + foundation + ", Structure=" + structure + ", Roof=" + roof + "]";
   }
}

Step 2: Builder Interface
public interface HouseBuilder {
    void buildFoundation();
    void buildStructure();
    void buildRoof();
    House getHouse();
}

Step 3: Concrete Builders
public class WoodenHouseBuilder implements HouseBuilder {
    private House house = new House();

    @Override
    public void buildFoundation() {
        house.setFoundation("Wooden Foundation");
    }

    @Override
    public void buildStructure() {
        house.setStructure("Wooden Structure");
    }

    @Override
    public void buildRoof() {
        house.setRoof("Wooden Roof");
    }

    @Override
    public House getHouse() {
        return house;
    }
}

public class StoneHouseBuilder implements HouseBuilder {
    private House house = new House();

    @Override
    public void buildFoundation() {
        house.setFoundation("Stone Foundation");
    }

    @Override
    public void buildStructure() {
        house.setStructure("Stone Structure");
    }

    @Override
    public void buildRoof() {
        house.setRoof("Stone Roof");
    }

    @Override
    public House getHouse() {
        return house;
    }
}

Step 4: Director

public class HouseDirector {
    private HouseBuilder builder;

    public HouseDirector(HouseBuilder builder) {
        this.builder = builder;
    }

    public House constructHouse() {
        builder.buildFoundation();
        builder.buildStructure();
        builder.buildRoof();
        return builder.getHouse();
    }
}

Step 5: Client Code

public class BuilderDemo {
    public static void main(String[] args) {
        HouseBuilder woodenBuilder = new WoodenHouseBuilder();
        HouseDirector director = new HouseDirector(woodenBuilder);
        House woodenHouse = director.constructHouse();
        System.out.println(woodenHouse);

        HouseBuilder stoneBuilder = new StoneHouseBuilder();
        director = new HouseDirector(stoneBuilder);
        House stoneHouse = director.constructHouse();
        System.out.println(stoneHouse);
    }
}

Output Example
House [Foundation=Wooden Foundation, Structure=Wooden Structure, Roof=Wooden Roof]
House [Foundation=Stone Foundation, Structure=Stone Structure, Roof=Stone Roof]

Abstract Factory Pattern

Factory of factories — gives you a group of related objects (like a complete theme or product set), not just one.

Key Idea: Encapsulates the creation of families of related objects.
Advantage: Ensures that products in a family are compatible and grouped logically.
✅ Why is Abstract Factory Pattern needed?
✅ When your system needs to create related objects together (e.g., Button + Checkbox in a UI toolkit).
✅ To ensure compatibility among created objects.
✅ To support multiple product families easily.
✅ It keeps code decoupled from concrete classes.
🔍 Real-life Analogy:
Imagine a Furniture Factory:
A ModernFurnitureFactory gives you: Modern Chair, Modern Table
A VictorianFurnitureFactory gives you: Victorian Chair, Victorian Table
You get a complete set of compatible products, not just one.

Use Case

Cross-platform UI: Creating compatible widgets like buttons and checkboxes for Windows, Mac, and Linux.
Gaming: Creating characters, weapons, and armor for different factions or races.
Payment Gateways: Creating configurations for PayPal, Stripe, and UPI systems.

🏦 Scenario:

You want to create banking-related objects: Loan and Account. Depending on the Bank (e.g., HDFC or SBI), the system should return the corresponding Account and Loan.

Step 1: Product Interfaces

interface Account {
void accountType();
}

interface Loan {
void loanType();
}

Step 2: Concrete Products – HDFC

class HDFCAccount implements Account {
public void accountType() {
System.out.println("HDFC Savings Account");
}
}

class HDFCLoan implements Loan {
public void loanType() {
System.out.println("HDFC Home Loan");
}
}

Step 3: Concrete Products – SBI

class SBIAccount implements Account {
public void accountType() {
System.out.println("SBI Current Account");
}
}

class SBILoan implements Loan {
public void loanType() {
System.out.println("SBI Personal Loan");
}
}

Step 4: Abstract Factory

interface BankFactory {
Account createAccount();
Loan createLoan();
}

Step 5: Concrete Factories

class HDFCBankFactory implements BankFactory {
public Account createAccount() {
return new HDFCAccount();
}
public Loan createLoan() {
return new HDFCLoan();
}
}

class SBIBankFactory implements BankFactory {
public Account createAccount() {
return new SBIAccount();
}
public Loan createLoan() {
return new SBILoan();
}
}

Step 6: Factory Creator

public class Main {
public static void main(String[] args) {
BankFactory bankFactory = BankFactoryProvider.getBankFactory("hdfc");

Account account = bankFactory.createAccount();
account.accountType(); // Output: HDFC Savings Account

Loan loan = bankFactory.createLoan();
loan.loanType(); // Output: HDFC Home Loan
}
}

🧩 Creational Design Patterns Comparison Table

Feature / Pattern	Factory Method	Abstract Factory	Builder	Prototype	Singleton
Purpose	Create objects via subclass or method	Create related families of objects	Build complex object step-by-step	Clone existing object	Ensure one instance per app
Object Creation	Uses method/logic	Uses factory for families	Step-wise construction	Cloning existing object	Lazy or eager initialization
Flexibility	Medium	High	High	Medium	Low
Client Knows Concrete?	❌ No	❌ No	✅ Yes (via builder)	✅ Knows prototype	❌ No (direct access via static method)
When to Use	Vary object by input/context	Vary product family across app	Complex object (many configs, immutability)	Duplicate configured object	App-wide config/resource manager
Key Example (Game)	EnemyFactory → creates Orc/Zombie	GameUIFactory → MacOS/Windows buttons, menus	GameCharacterBuilder → Hero with weapons	Clone `Enemy` object with new HP	GameSettings (volume, level, user ID)
Main Advantage	Decouples instantiation	Easy to switch object families	Code clarity, immutability	Runtime object duplication	Global access to same instance
Main Drawback	Class explosion (many factories)	Many interfaces, can be abstract-heavy	Verbose if simple objects	Shallow vs. deep copy issues	Hidden dependencies, threading issues
Real-World Analogy	Pizza shop with types (Veg/Non-Veg)	Furniture factory (Modern/Victorian sets)	Meal builder (choose base, sides, drink)	Copying a filled form	Government ID system
Complexity	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐
Common Languages	Java, C#, Python	Java, C#	Java, Kotlin, Python	Java, C++, JS	Java, C#, Python

📌 Short Summary of Each Pattern

Factory – Choose one object from many possible (like selecting a payment method).
Abstract Factory – Choose a set of related objects (UI for Windows vs Mac).
Builder – Construct an object step by step, with flexibility.
Prototype – Clone an already existing object (pre-configured).
Singleton – Only one instance, used globally (like configuration manager).

→

Structural Design Pattern

Adapter Pattern:

23 min read

Jun 12, 2025

By Nitesh Synergy

Design Pattern

✅ What is a Design Pattern?

🎯 Why Are Design Patterns Needed?

🧱 Types of Design Patterns

1. Creational Patterns (Object creation)

✅ What is Singleton Pattern?

✅ Why Singleton is Important?

✅ When to Use Singleton? (Use Cases)

✅ Real-Time Project Example

🔹 Project: E-commerce Application

❌ When Not to Use Singleton

🔒 1. Private Constructor

📦 2. Static Instance Variable

🌍 3. Global Access Point

🧵 4. Thread Safety

❌ 5. Prevent Cloning

🔐 6. Serialization Safety

🪞 7. Reflection Safety

⚡ 8. Static Block for Eager Initialization

🛡️ 9. Use of final Keyword

📌 Guidelines for Using Singleton

Sol-2:

Lazy Initialization

Sol-5:

Reflection Safety:

🏦 1. Banking System Use Case

🔗 2. JDBC Connection Pool (Database Access Layer)

🎮 3. Gaming Application

🤖 4. AI/ChatGPT-Based App Use Case

📌 Summary Table

✅ GameEngineSingleton.java — Perfect Singleton for Game Engine

✅ GameEngineClient.java — Client Code to Use Singleton

Why Singleton is Ideal Here?

✅ When to Use Factory Pattern?

✅ Why Use It?

❌ Why NOT Use It?

🎯 Use Cases

Use Case: Drawing different shapes

→ Common Interface:

✅Why Factory is Ideal Here

Prototype Pattern

Use Case

Gaming Code: Cloning Game Entities

Builder Pattern

✅ Why is Builder Pattern needed?

🔍 Real-life Analogy:

Use Case

Abstract Factory Pattern

✅ Why is Abstract Factory Pattern needed?

🔍 Real-life Analogy:

Use Case

🏦 Scenario:

🧩 Creational Design Patterns Comparison Table

📌 Short Summary of Each Pattern

Structural Design Pattern

🛡️ 9. Use of `final` Keyword

✅ `GameEngineSingleton.java` — Perfect Singleton for Game Engine

✅ `GameEngineClient.java` — Client Code to Use Singleton