Introduction to JavaScript Design Patterns

Modern software applications often consist of thousands or even millions of lines of code. As applications grow, managing the codebase becomes increasingly difficult. Without a proper structure, code becomes repetitive, difficult to maintain, and prone to bugs.

Design Patterns provide proven, reusable solutions to common software design problems. They are not ready-made code or libraries but well-established templates that help developers write clean, maintainable, scalable, and reusable applications.

In modern JavaScript development, design patterns are widely used in frameworks and libraries such as React, Angular, Vue.js, Express.js, Node.js, and many enterprise applications.

Understanding design patterns helps developers move beyond writing code that simply works to writing code that is organized, extensible, and easy to maintain.

What are Design Patterns?

A Design Pattern is a reusable solution to a commonly occurring software design problem.

Rather than solving a problem from scratch every time, developers can apply a design pattern that has already been tested and refined over many years.

Design patterns describe:

• How objects interact
• How responsibilities are distributed
• How code should be organized
• How software can remain flexible as requirements change

A design pattern is not a complete program. Instead, it provides a blueprint that developers adapt to their own applications.

Definition of Design Pattern

A design pattern is:

A general, reusable solution to a commonly occurring problem in software design.

It is important to understand that a design pattern is not:

• A programming language
• A framework
• A library
• A complete algorithm

Instead, it is a recommended approach for solving recurring software design challenges.

Why Do We Need Design Patterns?

Suppose you are building an online shopping application.

Initially, you might have only a few JavaScript files.

As new features are added, the project grows.

Without proper organization:

• Functions become duplicated.
• Objects become tightly coupled.
• Updating one module affects many others.
• Debugging becomes difficult.
• Testing requires more effort.

Design patterns solve these problems by providing standardized approaches to software architecture.

Real-World Analogy

Imagine constructing a residential building.

Architects do not redesign every door, staircase, or window from scratch. Instead, they use proven architectural designs that have been successfully implemented in many buildings.

Similarly, software developers reuse proven software design solutions.

Likewise,

History of Design Patterns

The concept of design patterns originated in architecture.

Architect Christopher Alexander introduced reusable architectural design concepts in the 1970s.

Later, four software engineers adapted these ideas for software development.

They published the famous book:

Design Patterns: Elements of Reusable Object-Oriented Software (1994)

These authors became known as the Gang of Four (GoF).

The Gang of Four (GoF)

The Gang of Four consists of:

• Erich Gamma
• Richard Helm
• Ralph Johnson
• John Vlissides

Their book introduced 23 classic software design patterns, which continue to influence modern software engineering.

Why are Design Patterns Important in JavaScript?

JavaScript has evolved from a simple scripting language into one of the world’s most widely used programming languages.

Today it powers:

• Frontend applications
• Backend servers
• Mobile applications
• Desktop applications
• Progressive Web Apps
• Cloud services

As applications become larger, developers require standardized methods for organizing code.

Design patterns help developers:

• Reduce code duplication
• Improve maintainability
• Increase scalability
• Encourage reusable code
• Simplify debugging
• Improve collaboration among teams

Where are Design Patterns Used?

Design patterns appear throughout modern JavaScript development.

Examples include:

Even if developers are unaware of them, they are already using design patterns through modern frameworks.

Characteristics of Good Design Patterns

A good design pattern should:

• Solve a common problem.
• Be reusable.
• Improve code readability.
• Promote loose coupling.
• Encourage maintainability.
• Support scalability.
• Be easy to understand.

Design Patterns vs Algorithms

Many beginners confuse design patterns with algorithms.

They are fundamentally different.

Design Patterns vs Frameworks

A framework provides ready-made functionality.

A design pattern provides guidance.

Example:

React is a framework/library.

Singleton is a design pattern.

Design Patterns vs Libraries

Libraries provide reusable code.

Design patterns provide reusable design solutions.

Benefits of Design Patterns

Using design patterns provides several advantages.

Improved Code Reusability

Developers can reuse proven solutions instead of creating new ones every time.

Better Maintainability

Well-organized applications are easier to update and debug.

Scalability

Applications can grow without becoming difficult to manage.

Loose Coupling

Objects become less dependent on one another.

This improves flexibility.

Better Team Collaboration

Standard design approaches make code easier for other developers to understand.

Faster Development

Developers spend less time solving recurring architectural problems.

Limitations of Design Patterns

Although design patterns are extremely useful, they should not be used everywhere.

Some limitations include:

• Additional complexity for small applications.
• Learning curve for beginners.
• Incorrect pattern selection may reduce performance.
• Overengineering simple applications.

When Should You Use Design Patterns?

Use design patterns when:

• Building medium or large applications.
• Developing reusable components.
• Working in a development team.
• Designing scalable software.
• Solving recurring architectural problems.

Avoid unnecessary patterns in very small applications.

Categories of Design Patterns

The Gang of Four classified design patterns into three major categories.

1. Creational Design Patterns

These patterns focus on object creation.

Instead of creating objects directly, they provide flexible methods for object creation.

Examples:

• Singleton
• Factory
• Prototype

2. Structural Design Patterns

These patterns describe how objects and classes are organized into larger structures.

Examples:

• Module
• Adapter
• Facade
• Decorator

3. Behavioral Design Patterns

Behavioral patterns focus on communication between objects.

Examples:

• Observer
• Strategy
• Command
• State

Design Pattern Selection Workflow

Design Pattern Categories at a Glance

Why Learn Design Patterns Before React and Node.js?

Modern JavaScript frameworks rely heavily on design patterns.

For example:

• React uses component-based architecture and observer concepts.
• Redux follows the observer pattern.
• Express uses middleware, which resembles the chain of responsibility pattern.
• Node.js uses the module pattern extensively.

Understanding design patterns first makes learning these frameworks much easier.

Best Practices

• Choose a pattern only when it solves a real problem.
• Keep designs simple and readable.
• Prefer composition over unnecessary inheritance.
• Follow SOLID principles alongside design patterns.
• Avoid using patterns just because they are popular.

Common Mistakes

• Treating design patterns as complete solutions.
• Applying patterns to very small programs.
• Using multiple patterns unnecessarily.
• Ignoring readability in favor of complexity.
• Choosing a pattern without understanding the problem it solves.

Singleton Design Pattern in JavaScript

What is the Singleton Pattern?

The Singleton Pattern is a Creational Design Pattern that ensures only one instance of a class is created throughout the application’s lifecycle.

Whenever another object is requested, the existing object is returned instead of creating a new one.

In simple words,

One Class → One Object → Shared Everywhere

Singleton is one of the most widely used design patterns in JavaScript because many applications require only a single instance of certain objects such as configuration managers, database connections, loggers, authentication services, and caches.

Definition

The Singleton Pattern is a design pattern that:

• Creates only one object.
• Provides a global access point.
• Prevents multiple object creation.
• Shares the same instance throughout the application.

Why Do We Need the Singleton Pattern?

Imagine a web application where every page creates a new database connection.

Problems:

• Unnecessary memory usage
• Multiple active connections
• Slower performance
• Difficult resource management

Instead,

Every module uses the same database connection.

This is exactly what the Singleton Pattern provides.

Real-World Analogy

Consider a Printer in an office.

Creating a separate printer for every employee would waste resources.

Singleton works in the same way.

Characteristics of Singleton Pattern

A Singleton object:

• Has only one instance.
• Is created only once.
• Is shared throughout the application.
• Provides global access.
• Prevents duplicate objects.

Singleton Workflow

Application Starts

        │

        ▼

Singleton Requested

        │

        ▼

Instance Exists?

   ┌───────────────┐

   │               │

  No              Yes

   │               │

   ▼               ▼

Create Object   Return Existing

        │

        └──────────────► Shared Instance

Normal Object Creation

Without Singleton

class Database{

}

const db1 = new Database();

const db2 = new Database();

console.log(db1 === db2);

false

Explanation

Every new keyword creates a completely new object.

Singleton Object Creation

With Singleton

Implementing Singleton Pattern

There are multiple ways to implement Singleton in JavaScript.

• Using ES6 Classes
• Using Closures
• Using Modules
• Using Static Properties

The ES6 Class approach is the easiest to understand.

Example 1: Basic Singleton Class

class Singleton{

    static instance;

    constructor(){

        if(Singleton.instance){

            return Singleton.instance;

        }

        Singleton.instance=this;

    }

}

const obj1=new Singleton();

const obj2=new Singleton();

console.log(obj1===obj2);

true

Explanation

When the second object is created,

JavaScript checks

Singleton.instance

the constructor returns the same object.

Memory Representation

Both variables point to the same object.

Example 2: Configuration Manager

Many applications load configuration only once.

class Configuration{

    static instance;

    constructor(){

        if(Configuration.instance){

            return Configuration.instance;

        }

        this.theme="Light";

        this.language="English";

        Configuration.instance=this;

    }

}

const config1=new Configuration();

const config2=new Configuration();

config2.theme="Dark";

console.log(config1.theme);

console.log(config2.theme);

Dark

Dark

Explanation

Both variables reference the same configuration object.

Changing one object automatically updates the other.

Example 3: Logger

Applications usually require only one logger.

class Logger{

    static instance;

    constructor(){

        if(Logger.instance){

            return Logger.instance;

        }

        Logger.instance=this;

    }

    log(message){

        console.log("[LOG]",message);

    }

}

const logger1=new Logger();

const logger2=new Logger();

logger1.log("Application Started");

console.log(

logger1===logger2

);

[LOG] Application Started

true

Example 4: Local Storage Manager

Instead of repeatedly accessing Local Storage directly,

one manager controls all operations.

class StorageManager{

    static instance;

    constructor(){

        if(StorageManager.instance){

            return StorageManager.instance;

        }

        StorageManager.instance=this;

    }

    save(key,value){

        localStorage.setItem(

        key,

        value

        );

    }

    get(key){

        return localStorage.getItem(

        key

        );

    }

}

const storage=new StorageManager();

storage.save(

"name",

"Akshay"

);

console.log(

storage.get("name")

);

Akshay

Example 5: Theme Manager

class ThemeManager{

    static instance;

    constructor(){

        if(ThemeManager.instance){

            return ThemeManager.instance;

        }

        this.theme="Light";

        ThemeManager.instance=this;

    }

    changeTheme(theme){

        this.theme=theme;

    }

}

const t1=new ThemeManager();

const t2=new ThemeManager();

t2.changeTheme("Dark");

console.log(t1.theme);

Dark

Singleton vs Normal Class

Advantages of Singleton Pattern

Memory Efficient

Only one object is created.

Global Access

Every module accesses the same instance.

Better Resource Management

Useful for database connections and loggers.

Prevents Duplicate Objects

Avoids unnecessary object creation.

Easier Configuration Management

Configuration remains consistent throughout the application.

Disadvantages of Singleton Pattern

• Behaves like a global variable if overused.
• Difficult to unit test.
• Reduces flexibility.
• Can introduce hidden dependencies.
• Not suitable for every class.

Real-World Applications

Singleton Pattern is commonly used for:

• Database Connection
• Logger
• Configuration Manager
• Authentication Manager
• Cache Manager
• Session Manager
• Theme Manager
• API Client
• File Manager
• Printer Manager

When Should You Use Singleton?

Use Singleton when:

• Only one object should exist.
• The object is shared by the entire application.
• Creating multiple instances wastes resources.
• Global access is required.

When Should You Avoid Singleton?

Avoid Singleton when:

• Multiple independent objects are needed.
• Each user requires a separate object.
• The object stores user-specific data.
• Testing requires isolated instances.

Best Practices

• Use Singleton only when a single shared instance is truly required.
• Keep the Singleton class focused on one responsibility.
• Avoid storing unrelated business logic inside a Singleton.
• Use lazy initialization when object creation is expensive.
• Combine Singleton with modules for better organization.

Common Mistakes

• Creating multiple instances accidentally.
• Using Singleton for every class.
• Treating Singleton as a replacement for dependency injection.
• Storing excessive application state in a Singleton.
• Making Singleton responsible for unrelated tasks.

Interview Questions

1. What is the Singleton Pattern?

A design pattern that ensures only one instance of a class exists and provides global access to it.

2. Why is Singleton considered a Creational Pattern?

Because it controls how objects are created and ensures that only one object is instantiated.

3. Name three real-world applications of the Singleton Pattern.

• Database Connection
• Logger
• Configuration Manager

4. What is the main advantage of Singleton?

It saves memory and ensures consistent access to shared resources.

5. Can Singleton reduce application performance?

If misused, it can create unnecessary global state and make applications harder to test and maintain.

Factory Design Pattern in JavaScript

What is the Factory Pattern?

The Factory Pattern is a Creational Design Pattern that provides a centralized way to create objects without exposing the object creation logic to the client.

Instead of using the new keyword throughout the application, a factory function or factory class is responsible for creating and returning the appropriate object.

In simple words,

The Factory Pattern creates objects for you based on the provided requirements.

This makes applications more flexible, scalable, and easier to maintain.

Definition

The Factory Pattern is a design pattern that:

• Creates objects without exposing object creation logic.
• Centralizes object creation.
• Returns different object types based on input.
• Reduces coupling between object creation and object usage.

Why Do We Need the Factory Pattern?

Suppose you are building an e-commerce website.

Without the Factory Pattern:

const admin = new Admin();
const customer = new Customer();
const seller = new Seller();

Problems:

• Repeated object creation code
• Difficult maintenance
• Hard to introduce new object types
• Tight coupling

Instead, use a factory.

const user = UserFactory.createUser("Admin");

Real-World Analogy

Imagine ordering a coffee from a coffee shop.

You don’t prepare the coffee yourself.

Instead,

Customer

     │

     ▼

Coffee Factory

     │

───────────────

│      │      │

Espresso

Latte

Cappuccino

The factory prepares and returns the correct coffee.

Characteristics of Factory Pattern

A Factory:

• Centralizes object creation.
• Hides creation logic.
• Creates different object types.
• Makes applications scalable.
• Reduces duplicate code.

Factory Pattern Workflow

Application

      │

      ▼

Factory

      │

Select Object Type

      │

───────────────

│       │      │

Car    Bike   Truck

      │

      ▼

Return Object

Traditional Object Creation

Without Factory

class Car{}

class Bike{}

const car = new Car();

const bike = new Bike();

Every object is created manually.

Object Creation Using Factory

Example 1: Simple Factory Function

function vehicleFactory(type){

    if(type==="car"){

        return {

            type:"Car"

        };

    }

    if(type==="bike"){

        return{

            type:"Bike"

        };

    }

}

const vehicle1=

vehicleFactory("car");

const vehicle2=

vehicleFactory("bike");

console.log(vehicle1);

console.log(vehicle2);

{type:"Car"}

{type:"Bike"}

Explanation

Instead of writing

new Car();

new Bike();

the factory creates the correct object automatically.

Example 2: Vehicle Factory Using Classes

class Car{

    drive(){

        console.log(

        "Driving Car"

        );

    }

}

class Bike{

    drive(){

        console.log(

        "Riding Bike"

        );

    }

}

class VehicleFactory{

    static createVehicle(type){

        if(type==="car")

            return new Car();

        if(type==="bike")

            return new Bike();

    }

}

const vehicle=

VehicleFactory.createVehicle("car");

vehicle.drive();

Output

Driving Car

Example 3: Employee Factory

class Manager{

    work(){

        console.log(

        "Managing Team"

        );

    }

}

class Developer{

    work(){

        console.log(

        "Writing Code"

        );

    }

}

class EmployeeFactory{

    static createEmployee(role){

        if(role==="manager")

            return new Manager();

        if(role==="developer")

            return new Developer();

    }

}

const employee=

EmployeeFactory.createEmployee(

"developer"

);

employee.work();

Output

Writing Code

Example 4: Notification Factory

Many applications send notifications through different channels.

Notification

      │

───────────────

│       │      │

Email   SMS   Push

class Email{

    send(){

        console.log(

        "Email Sent"

        );

    }

}

class SMS{

    send(){

        console.log(

        "SMS Sent"

        );

    }

}

class Push{

    send(){

        console.log(

        "Push Notification Sent"

        );

    }

}

class NotificationFactory{

    static create(type){

        switch(type){

            case "email":

                return new Email();

            case "sms":

                return new SMS();

            case "push":

                return new Push();

        }

    }

}

const notification=

NotificationFactory.create(

"email"

);

notification.send();

Email Sent

Example 5: Authentication Factory

Modern applications support multiple authentication methods.

Authentication

       │

───────────────

│        │

Google  GitHub

         │

      Facebook

class Google{

    login(){

        console.log(

        "Google Login"

        );

    }

}

class GitHub{

    login(){

        console.log(

        "GitHub Login"

        );

    }

}

class AuthenticationFactory{

    static create(provider){

        switch(provider){

            case "google":

                return new Google();

            case "github":

                return new GitHub();

        }

    }

}

const auth=

AuthenticationFactory.create(

"github"

);

auth.login();

Output

GitHub Login

Example 6: Shape Factory

class Circle{

    draw(){

        console.log("Circle");

    }

}

class Rectangle{

    draw(){

        console.log("Rectangle");

    }

}

class ShapeFactory{

    static create(shape){

        if(shape==="circle")

            return new Circle();

        if(shape==="rectangle")

            return new Rectangle();

    }

}

const object=

ShapeFactory.create(

"circle"

);

object.draw();

Output

Circle

Factory Pattern Workflow Example

factory-pattern-workflow-example

Factory Pattern vs Constructor Function

Factory Pattern vs Singleton Pattern

Advantages of Factory Pattern

Encapsulates Object Creation

Clients do not need to know how objects are created.

Improves Maintainability

Changes in object creation are made only in the factory.

Reduces Code Duplication

Object creation logic exists in one place.

Improves Scalability

Adding a new object type usually requires updating only the factory.

Loose Coupling

The client depends on the factory, not on concrete classes.

Disadvantages of Factory Pattern

• Additional abstraction.
• More classes/functions.
• Slightly increased complexity.
• Not necessary for very small applications.

Real-World Applications

Factory Pattern is commonly used for:

• UI Component Creation
• Authentication Systems
• Database Drivers
• Payment Gateways
• Notification Services
• API Clients
• Vehicle Manufacturing Systems
• Game Character Creation
• Cloud Service Providers
• Plugin Systems

When Should You Use Factory Pattern?

Use the Factory Pattern when:

• Multiple object types are required.
• Object creation logic is complex.
• You want to reduce coupling.
• New object types may be added later.
• You want to centralize object creation.

When Should You Avoid Factory Pattern?

Avoid using the Factory Pattern when:

• Only one simple object is created.
• Object creation logic is straightforward.
• Additional abstraction provides no benefit.
• The application is very small.

Best Practices

• Keep factory methods focused only on object creation.
• Avoid placing business logic inside the factory.
• Use meaningful factory names such as UserFactory or PaymentFactory.
• Return objects that share a common interface when possible.
• Use switch statements or mapping objects for readability when handling many object types.

Common Mistakes

• Creating factories for trivial objects.
• Mixing business logic with object creation.
• Returning inconsistent object structures.
• Creating a very large factory responsible for unrelated object types.
• Ignoring error handling for unsupported object requests.

Prototype Design Pattern in JavaScript

What is the Prototype Pattern?

The Prototype Pattern is a Creational Design Pattern that creates new objects by cloning or inheriting from an existing object instead of creating them from scratch.

Unlike many object-oriented programming languages that rely solely on classes, JavaScript uses a prototype-based inheritance model. Every object in JavaScript has an internal link to another object called its prototype.

In simple words,

Prototype Pattern allows new objects to inherit properties and methods from existing objects.

This approach reduces memory usage, promotes code reuse, and improves performance by sharing methods across multiple objects.

Definition

The Prototype Pattern is a design pattern that:

• Creates new objects from existing objects.
• Shares methods through prototypes.
• Reduces duplicate code.
• Supports inheritance without copying methods into every object.

Why Do We Need the Prototype Pattern?

Suppose you create 1,000 student objects.

Without prototypes:

const student1 = {
    display() { }
};

const student2 = {
    display() { }
};

const student3 = {
    display() { }
};

Each object contains its own copy of the display() method.

This wastes memory.

Instead,

Student Object

        │

        ▼

Prototype

        │

        ▼

display()

        ▲

────────┼────────

│       │       │

Student1 Student2 Student3

Real-World Analogy

Imagine a photocopy machine.

Original Document

        │

        ▼

Photocopy Machine

        │

───────────────

│       │       │

Copy1  Copy2  Copy3

Instead of creating each document manually, copies are produced from the original.

Similarly, the Prototype Pattern creates new objects using an existing prototype.

Characteristics of Prototype Pattern

• Creates objects through cloning or inheritance.
• Shares common methods.
• Reduces memory consumption.
• Improves performance.
• Supports prototype-based inheritance.

Prototype Workflow

Create Prototype Object

        │

        ▼

Add Shared Methods

        │

        ▼

Create New Objects

        │

───────────────

│       │       │

Object1 Object2 Object3

        │

        ▼

Shared Prototype Methods

Understanding JavaScript Prototypes

Every JavaScript object has an internal prototype.

const student = {

    name:"Akshay"

};

console.log(

Object.getPrototypeOf(student)

);

Output

{}

Prototype Chain

When JavaScript searches for a property:

1. It checks the current object.
2. If not found, it checks the prototype.
3. If still not found, it checks the next prototype.
4. The process continues until null is reached.

Prototype Chain Workflow

Object

   │

Property Found?

│            │

Yes         No

│            ▼

Return     Prototype

              │

       Property Found?

         │          │

        Yes        No

         │          ▼

      Return      Next Prototype

                      │

                    null

Example 1: Prototype Method

function Student(name){

    this.name=name;

}

Student.prototype.display=function(){

    console.log(

    "Student :",this.name

    );

};

const student1=

new Student("Akshay");

const student2=

new Student("Rahul");

student1.display();

student2.display();

Output

Student : Akshay

Student : Rahul

Explanation

The display() method exists only once in memory and is shared by every Student object.

Example 2: Sharing Methods

function Employee(name){

    this.name=name;

}

Employee.prototype.work=function(){

    console.log(

    this.name+

    " is Working"

    );

};

const emp1=

new Employee("Rahul");

const emp2=

new Employee("Sneha");

emp1.work();

emp2.work();

Output

Rahul is Working

Sneha is Working

Example 3: Using Object.create()

JavaScript provides the Object.create() method to create objects from an existing prototype.

Syntax

Object.create(prototypeObject);

Example

const person={

    greet(){

        console.log(

        "Welcome"

        );

    }

};

const student=

Object.create(person);

student.greet();

Welcome

Explanation

The student object does not define the greet() method.

Instead, it inherits the method from person.

Example 4: Adding Properties

const person={

    greet(){

        console.log("Hello");

    }

};

const employee= Object.create(person);

employee.name="Akshay";

console.log(employee.name);

employee.greet();

Output

Akshay

Hello

Example 5: Prototype Inheritance

const animal={

    eat(){

        console.log(

        "Eating"

        );

    }

};

const dog=

Object.create(animal);

dog.bark=function(){

    console.log(

    "Barking"

    );

};

dog.eat();

dog.bark();

Output

Eating

Barking

Example 6: Checking Prototype

const student={

name:"Akshay"

};

console.log(

Object.getPrototypeOf(student)

);

Example 7: Setting Prototype

const person={

greet(){

console.log("Hello");

}

};

const student={

name:"Akshay"

};

Object.setPrototypeOf(

student,

person

);

student.greet();

Output

Hello

Prototype Chain Visualization

Student Object

        │

        ▼

Student Prototype

        │

        ▼

Object Prototype

        │

        ▼

      null

Prototype vs ES6 Class

Although ES6 introduced the class keyword, JavaScript still uses prototypes internally.

Consider the following example:

class Student{

    display(){

        console.log("Student");

    }

}

const student=

new Student();

student.display();

Internally, JavaScript stores the display() method inside the class prototype.

Proof

console.log(

Student.prototype

);

Constructor Function vs Prototype Method

Constructor Function

function Student(name){

    this.name=name;

    this.display=function(){

        console.log(this.name);

    };

}

Every object receives its own copy of the display() method.

Prototype Method

function Student(name){

    this.name=name;

}

Student.prototype.display=function(){

    console.log(this.name);

};

Only one copy of the method exists.

Memory Comparison

Without Prototype

Student1 → display()

Student2 → display()

Student3 → display()

Three separate methods

With Prototype

Student1

Student2

Student3

        │

        ▼

Shared display()

Prototype vs Factory Pattern

Advantages of Prototype Pattern

Memory Efficient

Methods are shared instead of duplicated.

Faster Object Creation

Objects inherit existing functionality.

Code Reusability

Common methods exist in one location.

Better Performance

Less memory is consumed for frequently created objects.

Native to JavaScript

Prototype-based inheritance is built into the language.

Disadvantages of Prototype Pattern

• Can be confusing for beginners.
• Long prototype chains make debugging harder.
• Modifying a prototype affects all objects using it.
• Less intuitive than ES6 classes.

Real-World Applications

Prototype Pattern is commonly used for:

• DOM Elements
• React Component Internals
• Node.js Objects
• Browser APIs
• Custom JavaScript Libraries
• Object Cloning
• Plugin Systems
• Game Development

When Should You Use Prototype Pattern?

Use the Prototype Pattern when:

• Many similar objects are created.
• Shared methods are required.
• Memory optimization is important.
• Prototype-based inheritance is appropriate.

When Should You Avoid Prototype Pattern?

Avoid using the Prototype Pattern when:

• Objects have completely unrelated behavior.
• Team members are unfamiliar with prototypes.
• Simpler class-based solutions are sufficient.

Best Practices

• Store shared methods on the prototype rather than inside constructors.
• Prefer ES6 classes for readability while understanding that they use prototypes internally.
• Keep prototype chains shallow to simplify debugging.
• Use Object.create() when prototype-based inheritance is appropriate.
• Avoid modifying built-in prototypes such as Array.prototype or Object.prototype in production applications.

Common Mistakes

• Defining methods inside constructors when they can be shared.
• Confusing prototypes with object copying.
• Overwriting a prototype without restoring the constructor reference.
• Creating unnecessarily deep prototype chains.
• Modifying native JavaScript prototypes in shared codebases.

Module Design Pattern in JavaScript

What is the Module Pattern?

The Module Pattern is a Structural Design Pattern that organizes code into independent, reusable modules while hiding internal implementation details.

A module groups related variables, functions, and objects together and exposes only the functionality that should be accessible from outside.

In simple words,

The Module Pattern helps organize code by keeping private data hidden and exposing only the required public methods.

It is one of the most widely used design patterns in JavaScript applications because it improves maintainability, avoids global variables, and promotes code reuse.

Definition

The Module Pattern is a design pattern that:

• Encapsulates related functionality.
• Hides private variables and methods.
• Exposes a controlled public API.
• Prevents global namespace pollution.
• Improves code organization.

Why Do We Need the Module Pattern?

Suppose an application contains hundreds of variables.

let username;

let password;

let cart;

let products;

let orders;

let payment;

let total;

let userRole;

All these variables exist in the global scope.

Problems include:

• Variable name conflicts.
• Accidental modification.
• Difficult debugging.
• Poor maintainability.
• Global namespace pollution.

Instead, group related functionality inside a module.

Real-World Analogy

Consider a Television Remote Control.

Television

│

├── Internal Circuit

├── Processor

├── Memory

└── Software

        ▲

        │

Remote Control

│

├── Power

├── Volume

└── Channel

Users interact only with the remote’s buttons.

The internal electronics remain hidden.

Similarly, a module exposes only the necessary functions while keeping implementation details private.

Characteristics of Module Pattern

A module:

• Groups related code.
• Protects private data.
• Exposes selected methods.
• Improves maintainability.
• Prevents global variable conflicts.

Module Pattern Workflow

Application

      │

      ▼

Module

      │

───────────────

│               │

Private Data   Public API

      │               │

Hidden      Accessible

Traditional JavaScript

Without modules:

let total = 0;

function add(){

}

function remove(){

}

Everything is accessible globally.

Module Organization

Shopping Module

│

├── Products

├── Cart

├── Payment

├── Orders

└── Reports

Each module is responsible for a specific task.

Creating Modules Using IIFE

Before ES6 modules were introduced, JavaScript developers used an Immediately Invoked Function Expression (IIFE).

What is an IIFE?

An IIFE is a function that executes immediately after it is defined.

Syntax

(function(){

})();

Why Use IIFE?

An IIFE creates a private scope.

Variables declared inside the function cannot be accessed from outside.

Example 1

(function(){

    console.log(

    "Module Loaded"

    );

})();

Output

Module Loaded

Example 2: Private Variable

const Counter=(function(){

    let count=0;

    return{

        increment(){

            count++;

            console.log(count);

        }

    };

})();

Counter.increment();

Counter.increment();

1

2

Explanation

The variable count is private.

Only the increment() method can modify it.

Attempting Direct Access

console.log(Counter.count);

undefined

Public and Private Members

Module

│

├── Private Variables

├── Private Functions

│

└── Public Methods

Example 3: Calculator Module

const Calculator=(function(){

    function add(a,b){

        return a+b;

    }

    function subtract(a,b){

        return a-b;

    }

    return{

        add,

        subtract

    };

})();

console.log(

Calculator.add(20,10)

);

console.log(

Calculator.subtract(20,10)

);

Output

30

10

Example 4: Shopping Cart Module

const Cart=(function(){

    let items=[];

    function addItem(product){

        items.push(product);

    }

    function display(){

        console.log(items);

    }

    return{

        addItem,

        display

    };

})();

Cart.addItem("Laptop");

Cart.addItem("Mouse");

Cart.display();

Output

["Laptop","Mouse"]

Example 5: User Authentication Module

const Auth=(function(){

    let loggedIn=false;

    function login(){

        loggedIn=true;

        console.log("Logged In");

    }

    function logout(){

        loggedIn=false;

        console.log("Logged Out");

    }

    return{

        login,

        logout

    };

})();

Auth.login();

Auth.logout();

Output

Logged In

Logged Out

ES6 Modules

Modern JavaScript introduced ES6 Modules.

Instead of using IIFEs, developers now use separate JavaScript files.

Exporting Functions

math.js

export function add(a,b){

    return a+b;

}

export function multiply(a,b){

    return a*b;

}

Importing Functions

app.js

import{

add,

multiply

}

from "./math.js";

console.log(

add(10,20)

);

console.log(

multiply(5,6)

);

30

30

Default Export

export default class Student{

    constructor(name){

        this.name=name;

    }

}

Import Default Module

import Student

from "./student.js";

const student=

new Student("Akshay");

console.log(student.name);

Akshay

Named Export vs Default Export

Module Folder Structure

Project

│

├── index.html

├── app.js

├── modules

│     │

│     ├── math.js

│     ├── auth.js

│     ├── cart.js

│     └── users.js

└── assets

Module Pattern Workflow

Application

      │

      ▼

Import Module

      │

      ▼

Public Methods

      │

      ▼

Private Data Updated

Module Pattern vs Singleton Pattern

Module Pattern vs Factory Pattern

Advantages of Module Pattern

Encapsulation

Private data remains hidden.

Better Organization

Related functionality stays together.

Reusability

Modules can be imported wherever needed.

Avoids Global Variables

Each module has its own scope.

Easier Maintenance

Applications become modular and scalable.

Disadvantages of Module Pattern

• More files in large projects.
• Incorrect imports may cause errors.
• Circular dependencies can occur.
• Beginners may initially find module organization challenging.

Real-World Applications

The Module Pattern is commonly used for:

• React Components
• Node.js Applications
• Authentication Systems
• Shopping Cart Modules
• API Services
• Database Access Layers
• Utility Libraries
• Payment Services
• State Management
• Configuration Management

When Should You Use Module Pattern?

Use the Module Pattern when:

• Building medium or large applications.
• Organizing related functionality.
• Avoiding global variables.
• Creating reusable libraries.
• Working in development teams.

When Should You Avoid Module Pattern?

Avoid the Module Pattern when:

• The application is very small.
• There is no reusable functionality.
• A single script file is sufficient.

Best Practices

• Keep each module focused on a single responsibility.
• Export only what is required.
• Keep sensitive data private.
• Use meaningful module names.
• Prefer ES6 modules over IIFEs for modern applications.
• Avoid circular dependencies between modules.

Common Mistakes

• Exporting everything unnecessarily.
• Mixing unrelated functionality in the same module.
• Overusing global variables alongside modules.
• Forgetting to import required members.
• Creating very large modules with multiple responsibilities.

Interview Questions

1. What is the Module Pattern?

A structural design pattern that organizes related code into reusable modules while hiding private implementation details.

2. Why were IIFEs used before ES6 Modules?

To create private scope and avoid polluting the global namespace.

3. What is the difference between named exports and default exports?

Named exports allow multiple exported members, while a default export allows one primary exported member.

4. Why is the Module Pattern important in modern JavaScript?

It improves code organization, reusability, maintainability, and scalability.

5. Where is the Module Pattern commonly used?

React, Node.js, Express.js, Vue.js, Angular, utility libraries, and large-scale web applications.

Adapter Design Pattern in JavaScript

What is the Adapter Pattern?

The Adapter Pattern is a Structural Design Pattern that allows two incompatible interfaces to work together by converting one interface into another expected by the client.

In simple words,

The Adapter Pattern acts as a translator between two incompatible systems.

Instead of modifying existing code, an adapter sits between two components and converts requests into a format that both understand.

The Adapter Pattern is widely used in modern web applications for integrating third-party APIs, payment gateways, cloud services, legacy systems, and browser APIs.

Definition

The Adapter Pattern is a design pattern that:

• Converts one interface into another.
• Enables communication between incompatible systems.
• Reuses existing classes without modification.
• Acts as a bridge between old and new components.

Why Do We Need the Adapter Pattern?

Suppose your application expects payment through a common interface.

Application

      │

      ▼

processPayment()

However, different payment providers expose different methods.

PayPal

pay()

---------------------

Stripe

makePayment()

---------------------

Razorpay

startTransaction()

Without an adapter, your application must know the implementation details of every provider.

Using the Adapter Pattern:

Application

      │

      ▼

Payment Adapter

      │

───────────────

│       │       │

PayPal Stripe Razorpay

The application communicates only with the adapter, while the adapter translates requests to the appropriate payment provider.

Real-World Analogy

Consider an international traveler carrying a laptop charger.

Different countries use different electrical socket standards.

Laptop Charger

      │

      ▼

Power Adapter

      │

      ▼

Different Wall Socket

The charger does not change, and the wall socket does not change.

The adapter allows them to work together.

Similarly, software adapters connect incompatible interfaces without modifying either system.

Characteristics of Adapter Pattern

An Adapter:

• Converts incompatible interfaces.
• Promotes code reuse.
• Avoids modifying existing classes.
• Simplifies third-party integrations.
• Improves maintainability.

Adapter Pattern Workflow

Client

   │

   ▼

Adapter

   │

   ▼

Existing Service

   │

   ▼

Required Output

Without Adapter Pattern

class PayPal{

    pay(){

        console.log(

        "Payment using PayPal"

        );

    }

}

const paypal=new PayPal();

paypal.pay();

Now imagine another provider.

class Stripe{

    makePayment(){

        console.log(

        "Payment using Stripe"

        );

    }

}

The application now has two different method names.

Problem

PayPal

pay()

-----------------

Stripe

makePayment()

-----------------

Razorpay

startTransaction()

Different interfaces increase application complexity.

Solution

Create a common adapter.

Application

       │

       ▼

processPayment()

       │

       ▼

Payment Adapter

       │

───────────────

│       │       │

PayPal Stripe Razorpay

Example 1: Basic Adapter

class OldPrinter{

    print(){

        console.log(

        "Printing Document"

        );

    }

}

class PrinterAdapter{

    constructor(printer){

        this.printer=printer;

    }

    printDocument(){

        this.printer.print();

    }

}

const adapter=

new PrinterAdapter(

new OldPrinter()

);

adapter.printDocument();

Output

Printing Document

Explanation

The application expects a printDocument() method.

The old printer provides only print().

The adapter converts one method into another.

Example 2: Payment Gateway Adapter

class PayPal{

    pay(){

        console.log(

        "Paid using PayPal"

        );

    }

}

class PayPalAdapter{

    constructor(paypal){

        this.paypal=paypal;

    }

    processPayment(){

        this.paypal.pay();

    }

}

const payment=

new PayPalAdapter(

new PayPal()

);

payment.processPayment();

Paid using PayPal

Example 3: Stripe Adapter

class Stripe{

    makePayment(){

        console.log(

        "Paid using Stripe"

        );

    }

}

class StripeAdapter{

    constructor(stripe){

        this.stripe=stripe;

    }

    processPayment(){

        this.stripe.makePayment();

    }

}

const payment=

new StripeAdapter(

new Stripe()

);

payment.processPayment();

Paid using Stripe

Example 4: Legacy API Adapter

Suppose an old API returns:

{

fullName:"Akshay",

age:25

}

But your new application expects:

{

name:"Akshay",

age:25

}

Adapter:

class UserAdapter{

    constructor(user){

        this.user=user;

    }

    getUser(){

        return{

            name:this.user.fullName,

            age:this.user.age

        };

    }

}

const oldUser={

fullName:"Akshay",

age:25

};

const adapter=

new UserAdapter(oldUser);

console.log(

adapter.getUser()

);

Output

{

name:"Akshay",

age:25

}

Example 5: Temperature Converter Adapter

class Fahrenheit{

    getTemperature(){

        return 98.6;

    }

}

class CelsiusAdapter{

    constructor(sensor){

        this.sensor=sensor;

    }

    getTemperature(){

        return(

        (this.sensor.getTemperature()-32)

        *5/9

        );

    }

}

const sensor=

new CelsiusAdapter(

new Fahrenheit()

);

console.log(

sensor.getTemperature()

.toFixed(1)

);

Output

37.0

Example 6: File Reader Adapter

class TextReader{

    readText(){

        console.log(

        "Reading TXT File"

        );

    }

}

class ReaderAdapter{

    constructor(reader){

        this.reader=reader;

    }

    read(){

        this.reader.readText();

    }

}

const reader=

new ReaderAdapter(

new TextReader()

);

reader.read();

Output

Reading TXT File

Adapter Workflow Example

Application

      │

Expected Method

      │

      ▼

Adapter

      │

Converts Method

      │

      ▼

Existing Class

Object Adapter vs Class Adapter

Since JavaScript favors composition, Object Adapters are the preferred approach.

Adapter Pattern vs Facade Pattern

Advantages of Adapter Pattern

Code Reusability

Existing classes can be reused without modification.

Loose Coupling

Clients depend on adapters rather than implementation details.

Better Integration

Supports legacy systems and third-party libraries.

Easier Maintenance

Changes remain isolated inside the adapter.

Improved Scalability

Adding a new provider usually requires only a new adapter.

Disadvantages of Adapter Pattern

• Adds an extra abstraction layer.
• May increase the number of classes.
• Incorrect adapters can hide underlying problems.
• Overuse may complicate simple applications.

Real-World Applications

The Adapter Pattern is commonly used for:

• Payment Gateway Integration
• Legacy System Migration
• REST API Integration
• Cloud Service Providers
• Database Drivers
• Browser Compatibility
• File Format Conversion
• Authentication Providers
• Third-party SDK Integration
• IoT Device Communication

When Should You Use Adapter Pattern?

Use the Adapter Pattern when:

• Two systems expose different interfaces.
• Integrating third-party libraries.
• Migrating legacy applications.
• Reusing existing classes without modifying them.
• Supporting multiple service providers.

When Should You Avoid Adapter Pattern?

Avoid the Adapter Pattern when:

• Both systems already use compatible interfaces.
• The additional abstraction provides no value.
• The application is small and unlikely to require integration.

Best Practices

• Keep adapters focused on interface conversion only.
• Avoid embedding business logic inside adapters.
• Prefer composition over inheritance.
• Name adapters clearly, such as PaymentAdapter or UserAdapter.
• Use a consistent interface for all adapters.

Common Mistakes

• Using adapters to hide poor application design.
• Mixing conversion logic with business logic.
• Creating overly complex adapters.
• Modifying the original classes instead of wrapping them.
• Using multiple adapters where a single standardized interface would suffice.

Facade Design Pattern in JavaScript

What is the Facade Pattern?

The Facade Pattern is a Structural Design Pattern that provides a simple and unified interface to a complex subsystem.

Instead of interacting directly with multiple classes and methods, the client communicates with a single Facade object that coordinates all the underlying operations.

In simple words,

The Facade Pattern hides the complexity of a system by providing one simple interface.

This makes applications easier to use, maintain, and extend.

Definition

The Facade Pattern is a design pattern that:

• Simplifies complex systems.
• Provides a unified interface.
• Hides internal implementation.
• Reduces dependencies between clients and subsystems.
• Improves readability and maintainability.

Why Do We Need the Facade Pattern?

Imagine building an online shopping website.

To place an order, the application performs several operations.

Validate User

↓

Check Inventory

↓

Calculate Price

↓

Apply Discount

↓

Process Payment

↓

Generate Invoice

↓

Send Email

↓

Update Inventory

If the client has to call every service manually, the code becomes lengthy and difficult to maintain.

Instead,

Client

↓

OrderFacade.placeOrder()

↓

────────────────────────────────

Validate User

Check Inventory

Payment

Invoice

Email

Inventory Update

────────────────────────────────

The client makes only one method call.

Real-World Analogy

Imagine watching a movie using a home theater.

Without a facade,

Turn on TV

↓

Turn on Sound System

↓

Turn on DVD Player

↓

Select HDMI

↓

Adjust Volume

↓

Insert DVD

↓

Play Movie

Instead,

Press

"Watch Movie"

↓

Home Theater Controller

↓

TV

Sound System

DVD Player

Lights

The controller acts as the Facade.

Characteristics of Facade Pattern

A Facade:

• Provides a single entry point.
• Simplifies client interaction.
• Hides subsystem complexity.
• Improves maintainability.
• Promotes loose coupling.

Facade Pattern Workflow

Client

↓

Facade

↓

────────────────────────────

Subsystem A

Subsystem B

Subsystem C

Subsystem D

────────────────────────────

Without Facade Pattern

class Inventory{

    check(){

        console.log(

        "Inventory Checked"

        );

    }

}

class Payment{

    process(){

        console.log(

        "Payment Processed"

        );

    }

}

class Invoice{

    generate(){

        console.log(

        "Invoice Generated"

        );

    }

}

const inventory=new Inventory();

const payment=new Payment();

const invoice=new Invoice();

inventory.check();

payment.process();

invoice.generate();

Output

Inventory Checked

Payment Processed

Invoice Generated

The client must remember every step.

Using Facade Pattern

Client

↓

Order Facade

↓

Inventory

↓

Payment

↓

Invoice

Example 1: Order Facade

class Inventory{

    check(){

        console.log(

        "Inventory Checked"

        );

    }

}

class Payment{

    process(){

        console.log(

        "Payment Successful"

        );

    }

}

class Invoice{

    generate(){

        console.log(

        "Invoice Generated"

        );

    }

}

class OrderFacade{

    constructor(){

        this.inventory=new Inventory();

        this.payment=new Payment();

        this.invoice=

        new Invoice();

    }

    placeOrder(){

        this.inventory.check();

        this.payment.process();

        this.invoice.generate();

    }

}

const order=

new OrderFacade();

order.placeOrder();

Inventory Checked

Payment Successful

Invoice Generated

Explanation

The client only calls

order.placeOrder();

The facade internally coordinates all subsystem operations.

Example 2: Home Theater Facade

class TV{

    on(){

        console.log("TV On");

    }

}

class SoundSystem{

    on(){

        console.log("Sound System On");

    }

}

class DVD{

    play(){

        console.log("Movie Started");

    }

}

class HomeTheater{

    constructor(){

        this.tv=new TV();

        this.sound=new SoundSystem();

        this.dvd=new DVD();

    }

    watchMovie(){

        this.tv.on();

        this.sound.on();

        this.dvd.play();

    }

}

const theater=

new HomeTheater();

theater.watchMovie();

Output

TV On

Sound System On

Movie Started

Example 3: Banking Facade

class Account{

    verify(){

        console.log(

        "Account Verified"

        );

    }

}

class Loan{

    approve(){

        console.log(

        "Loan Approved"

        );

    }

}

class SMS{

    send(){

        console.log(

        "SMS Sent"

        );

    }

}

class BankFacade{

    constructor(){

        this.account=new Account();

        this.loan=new Loan();

        this.sms=new SMS();

    }

    applyLoan(){

        this.account.verify();

        this.loan.approve();

        this.sms.send();

    }

}

const bank=

new BankFacade();

bank.applyLoan();

Output

Account Verified

Loan Approved

SMS Sent

Example 4: Authentication Facade

class Database{

    connect(){

        console.log(

        "Database Connected"

        );

    }

}

class Authentication{

    login(){

        console.log(

        "User Authenticated"

        );

    }

}

class Session{

    create(){

        console.log(

        "Session Created"

        );

    }

}

class LoginFacade{

    constructor(){

        this.database=

        new Database();

        this.authentication=

        new Authentication();

        this.session=

        new Session();

    }

    login(){

        this.database.connect();

        this.authentication.login();

        this.session.create();

    }

}

const login=

new LoginFacade();

login.login();

Database Connected

User Authenticated

Session Created

Example 5: API Service Facade

class UserAPI{

    getUsers(){

        console.log(

        "Users Loaded"

        );

    }

}

class ProductAPI{

    getProducts(){

        console.log(

        "Products Loaded"

        );

    }

}

class OrderAPI{

    getOrders(){

        console.log(

        "Orders Loaded"

        );

    }

}

class APIFacade{

    constructor(){

        this.users=new UserAPI();

        this.products=new ProductAPI();

        this.orders=new OrderAPI();

    }

    loadDashboard(){

        this.users.getUsers();

        this.products.getProducts();

        this.orders.getOrders();

    }

}

const api=

new APIFacade();

api.loadDashboard();

Output

Users Loaded

Products Loaded

Orders Loaded

Facade Pattern Workflow Example

User Clicks Checkout

        │

        ▼

Order Facade

        │

──────────────────────────

│

Validate User

↓

Check Inventory

↓

Payment

↓

Invoice

↓

Email

──────────────────────────

        │

        ▼

Success

Facade vs Adapter

Facade vs Module Pattern

Advantages of Facade Pattern

Simplifies Client Code

Clients interact with one object instead of many.

Loose Coupling

Subsystem changes rarely affect client code.

Easier Maintenance

Complex logic remains inside the facade.

Improved Readability

Applications become easier to understand.

Better Reusability

The same facade can be reused across different modules.

Disadvantages of Facade Pattern

• Can become a large “God Object” if too many responsibilities are added.
• May hide useful subsystem functionality.
• Adds another abstraction layer.
• Poorly designed facades can become difficult to maintain.

Real-World Applications

Facade Pattern is commonly used for:

• Payment Processing
• Authentication Systems
• Banking Applications
• Shopping Carts
• Home Automation
• Cloud Services
• Database Wrappers
• REST API Services
• Media Players
• Enterprise Software

When Should You Use Facade Pattern?

Use the Facade Pattern when:

• A subsystem contains many classes.
• Clients need a simple interface.
• You want to reduce dependencies.
• Multiple operations are commonly executed together.

When Should You Avoid Facade Pattern?

Avoid the Facade Pattern when:

• The subsystem is already simple.
• Clients require direct access to all subsystem features.
• The extra abstraction provides little benefit.

Best Practices

• Keep the facade focused on coordination, not business logic.
• Do not expose unnecessary subsystem details.
• Create multiple small facades instead of one massive facade.
• Use meaningful method names such as placeOrder() or processPayment().
• Allow advanced users to access subsystems directly if necessary.

Common Mistakes

• Placing business logic inside the facade.
• Creating a facade with too many unrelated responsibilities.
• Using the facade as a replacement for all subsystem classes.
• Ignoring proper separation of concerns.
• Making the facade tightly coupled to client code.

Decorator Design Pattern in JavaScript

What is the Decorator Pattern?

The Decorator Pattern is a Structural Design Pattern that allows additional functionality to be added to an object dynamically without modifying its original implementation.

Instead of changing an existing class, the Decorator wraps the original object and extends its behavior.

In simple words,

The Decorator Pattern enhances an object’s functionality without changing its source code.

This approach follows the Open/Closed Principle (OCP), meaning software entities should be open for extension but closed for modification.

Definition

The Decorator Pattern is a design pattern that:

• Adds new functionality dynamically.
• Avoids modifying existing code.
• Uses composition instead of inheritance.
• Allows multiple decorators to be combined.
• Keeps classes simple and reusable.

Why Do We Need the Decorator Pattern?

Suppose you are building a coffee ordering system.

Initially, customers can order only plain coffee.

Coffee

Later, customers request additional options.

• Milk
• Sugar
• Chocolate
• Caramel
• Whipped Cream

Without the Decorator Pattern, you might create many classes.

Coffee

CoffeeWithMilk

CoffeeWithSugar

CoffeeWithChocolate

CoffeeWithMilkAndSugar

CoffeeWithMilkAndChocolate

CoffeeWithSugarAndChocolate

...

The number of classes grows rapidly.

Instead,

Coffee

      │

───────────────

│      │      │

Milk Sugar Chocolate

      │

      ▼

Customized Coffee

Decorators add features dynamically.

Real-World Analogy

Imagine purchasing a smartphone.

Initially, you buy only the phone.

Later, you add accessories.

Smartphone

      │

───────────────

│       │      │

Case Charger Earbuds

      │

      ▼

Customized Package

The smartphone itself does not change.

Accessories enhance its functionality.

The Decorator Pattern works in exactly the same way.

Characteristics of Decorator Pattern

A Decorator:

• Adds functionality dynamically.
• Wraps existing objects.
• Uses composition.
• Supports multiple decorators.
• Avoids modifying existing classes.

Decorator Pattern Workflow

Client

   │

   ▼

Decorator

   │

   ▼

Original Object

   │

   ▼

Enhanced Object

Without Decorator Pattern

class Coffee{

    cost(){

        return 100;

    }

}

const coffee=new Coffee();

console.log(coffee.cost());

Output

100

Adding toppings requires changing the class.

With Decorator Pattern

Coffee

   │

Milk Decorator

   │

Sugar Decorator

   │

Chocolate Decorator

   │

Final Coffee

Each decorator adds new behavior.

Example 1: Coffee Decorator

class Coffee{

    cost(){

        return 100;

    }

}

function addMilk(coffee){

    const originalCost=coffee.cost;

    coffee.cost=function(){

        return originalCost.call(this)+20;

    };

}

const coffee=new Coffee();

addMilk(coffee);

console.log(coffee.cost());

Output

120

Explanation

The original Coffee class remains unchanged.

The decorator simply extends its functionality.

Example 2: Multiple Decorators

class Coffee{

    cost(){

        return 100;

    }

}

function addMilk(coffee){

    const cost=coffee.cost;

    coffee.cost=function(){

        return cost.call(this)+20;

    };

}

function addSugar(coffee){

    const cost=coffee.cost;

    coffee.cost=function(){

        return cost.call(this)+10;

    };

}

const coffee=new Coffee();

addMilk(coffee);

addSugar(coffee);

console.log(coffee.cost());

Output

130

Execution Flow

Coffee

100

↓

Milk Decorator

120

↓

Sugar Decorator

130

Example 3: Logging Decorator

function logger(target){

    return function(...args){

        console.log(

        "Method Called"

        );

        return target(...args);

    };

}

function add(a,b){

    return a+b;

}

const decorated=

logger(add);

console.log(

decorated(10,20)

);

Output

Method Called

30

Example 4: User Permission Decorator

function adminOnly(action){

    return function(role){

        if(role==="Admin"){

            action();

        }

        else{

            console.log(

            "Access Denied"

            );

        }

    };

}

function deleteUser(){

    console.log(

    "User Deleted"

    );

}

const secureDelete=

adminOnly(deleteUser);

secureDelete("Admin");

secureDelete("Student");

Output

User Deleted

Access Denied

Example 5: API Caching Decorator

function cache(fn){

    const data={};

    return function(value){

        if(data[value]){

            console.log(

            "From Cache"

            );

            return data[value];

        }

        console.log(

        "Fetching"

        );

        data[value]=fn(value);

        return data[value];

    };

}

function square(number){

    return number*number;

}

const cachedSquare=

cache(square);

console.log(

cachedSquare(5)

);

console.log(

cachedSquare(5)

);

Output

Fetching

25

From Cache

25

Example 6: Express Middleware (Decorator Concept)

Express middleware behaves similarly to decorators.

function logger(req,res,next){

    console.log(

    "Request Received"

    );

    next();

}

Each middleware decorates the request before passing it to the next middleware.

Decorator Workflow Example

Request

     │

     ▼

Authentication

     │

     ▼

Logger

     │

     ▼

Validation

     │

     ▼

Controller

Each middleware adds additional functionality.

Decorator vs Inheritance

Decorator vs Facade

Advantages of Decorator Pattern

Dynamic Functionality

Features can be added at runtime.

Reusability

Decorators can be reused with different objects.

Follows Open/Closed Principle

Existing classes remain unchanged.

Flexible Design

Multiple decorators can be combined.

Better Maintainability

Avoids creating many subclasses.

Disadvantages of Decorator Pattern

• Too many decorators may increase complexity.
• Debugging wrapped objects can be difficult.
• Execution order matters when multiple decorators are applied.
• Overuse can reduce code readability.

Real-World Applications

Decorator Pattern is commonly used for:

• Express.js Middleware
• React Higher-Order Components (HOCs)
• Logging
• Authentication
• Authorization
• API Caching
• Input Validation
• Rate Limiting
• Compression
• Performance Monitoring

When Should You Use Decorator Pattern?

Use the Decorator Pattern when:

• Functionality should be added dynamically.
• Existing classes should remain unchanged.
• Different feature combinations are required.
• Composition is preferred over inheritance.

When Should You Avoid Decorator Pattern?

Avoid the Decorator Pattern when:

• The object behavior is unlikely to change.
• Simple inheritance provides a clearer solution.
• The added abstraction makes the code unnecessarily complex.

Best Practices

• Keep each decorator focused on a single responsibility.
• Preserve the original object’s interface.
• Apply decorators in a logical order.
• Avoid combining too many decorators.
• Prefer composition over deep inheritance hierarchies.

Common Mistakes

• Modifying the original class instead of decorating it.
• Mixing business logic into decorators.
• Creating decorators with multiple unrelated responsibilities.
• Applying decorators in an incorrect order.
• Using decorators where simple functions would be sufficient.

Observer Design Pattern in JavaScript

What is the Observer Pattern?

The Observer Pattern is a Behavioral Design Pattern that defines a one-to-many dependency between objects.

When one object (called the Subject) changes its state, all dependent objects (called Observers) are automatically notified and updated.

In simple words,

One object publishes changes, and many other objects automatically receive those updates.

This pattern is ideal for applications where multiple components need to stay synchronized without being tightly coupled.

Definition

The Observer Pattern is a design pattern that:

• Defines a one-to-many relationship.
• Automatically notifies dependent objects.
• Promotes loose coupling.
• Supports event-driven programming.
• Simplifies communication between objects.

Why Do We Need the Observer Pattern?

Imagine a stock market application.

When the stock price changes, multiple systems need to react.

• Mobile App
• Website Dashboard
• Email Service
• SMS Alerts
• Trading Bot

Without the Observer Pattern:

Stock Market

↓

Mobile

↓

Website

↓

Email

↓

SMS

↓

Trading Bot

The stock system must manually call every service.

Instead,

Stock Market

↓

Subject

↓

────────────────────────

│

Mobile

Website

Email

SMS

Trading Bot

────────────────────────

The Subject automatically notifies every observer.

Real-World Analogy

Consider a YouTube channel.

YouTube Channel

        │

Upload Video

        │

───────────────

│      │      │

Subscriber 1

Subscriber 2

Subscriber 3

Whenever a new video is uploaded, every subscriber receives a notification.

The channel does not need to contact each subscriber manually.

Characteristics of Observer Pattern

An Observer Pattern:

• Has one Subject.
• Has multiple Observers.
• Supports automatic notifications.
• Promotes loose coupling.
• Simplifies event communication.

Components of Observer Pattern

The Observer Pattern consists of two primary components.

Subject

The Subject:

• Stores observers.
• Registers observers.
• Removes observers.
• Notifies observers.

Observer

An Observer:

• Registers with the Subject.
• Receives updates.
• Performs actions when notified.

Observer Pattern Workflow

Subject

      │

State Changed

      │

      ▼

Notify()

      │

───────────────

│       │       │

Observer1

Observer2

Observer3

Example 1: Basic Observer Pattern

class Subject{

    constructor(){

        this.observers=[];

    }

    subscribe(observer){

        this.observers.push(observer);

    }

    notify(){

        this.observers.forEach(

            observer=>observer.update()

        );

    }

}

class Observer{

    update(){

        console.log(

        "Notification Received"

        );

    }

}

const subject=new Subject();

const observer1=new Observer();

const observer2=new Observer();

subject.subscribe(observer1);

subject.subscribe(observer2);

subject.notify();

Output

Notification Received

Notification Received

Explanation

The Subject does not know what each Observer actually does.

It simply calls:

observer.update();

This makes the system loosely coupled.

Example 2: Weather Station

class WeatherStation{

    constructor(){

        this.observers=[];

    }

    subscribe(observer){

        this.observers.push(observer);

    }

    setTemperature(temp){

        console.log(

        "Temperature:",temp

        );

        this.observers.forEach(

            observer=>observer.update(temp)

        );

    }

}

class Mobile{

    update(temp){

        console.log(

        "Mobile:",temp

        );

    }

}

class Website{

    update(temp){

        console.log(

        "Website:",temp

        );

    }

}

const station=

new WeatherStation();

station.subscribe(new Mobile());

station.subscribe(new Website());

station.setTemperature(32);

Output

Temperature: 32

Mobile: 32

Website: 32

Example 3: News Channel

class NewsChannel{

    constructor(){

        this.subscribers=[];

    }

    subscribe(user){

        this.subscribers.push(user);

    }

    publish(news){

        this.subscribers.forEach(

            subscriber=>subscriber.update(news)

        );

    }

}

class Subscriber{

    constructor(name){

        this.name=name;

    }

    update(news){

        console.log(

        this.name+

        " received: "+news

        );

    }

}

const channel=

new NewsChannel();

channel.subscribe(

new Subscriber("Akshay")

);

channel.subscribe(

new Subscriber("Rahul")

);

channel.publish(

"JavaScript ES2026 Released"

);

Output

Akshay received: JavaScript ES2026 Released

Rahul received: JavaScript ES2026 Released

Example 4: Chat Application

class ChatRoom{

    constructor(){

        this.users=[];

    }

    join(user){

        this.users.push(user);

    }

    send(message){

        this.users.forEach(

            user=>user.receive(message)

        );

    }

}

class User{

    constructor(name){

        this.name=name;

    }

    receive(message){

        console.log(

        this.name+

        ": "+message

        );

    }

}

const room=new ChatRoom();

room.join(new User("Akshay"));

room.join(new User("Sneha"));

room.send("Welcome!");

Output

Akshay: Welcome!

Sneha: Welcome!

Example 5: Stock Market Updates

class Stock{

    constructor(){

        this.investors=[];

    }

    subscribe(investor){

        this.investors.push(investor);

    }

    updatePrice(price){

        this.investors.forEach(

            investor=>investor.update(price)

        );

    }

}

class Investor{

    constructor(name){

        this.name=name;

    }

    update(price){

        console.log(

        this.name+

        " Stock Price: ₹"+price

        );

    }

}

const stock=new Stock();

stock.subscribe(

new Investor("Akshay")

);

stock.subscribe(

new Investor("Rahul")

);

stock.updatePrice(1850);

Output

Akshay Stock Price: ₹1850

Rahul Stock Price: ₹1850

Example 6: JavaScript Event Listeners

JavaScript’s built-in event system is one of the best examples of the Observer Pattern.

const button=

document.querySelector("button");

button.addEventListener(

"click",

function(){

    console.log(

    "Button Clicked"

    );

}
);

Here:

• Button → Subject
• Event Listener → Observer
• Click Event → Notification

Observer Workflow Example

User Clicks Button

        │

        ▼

Button

        │

Notify()

        │

──────────────────────

│          │

Animation

Save Data

Show Message

One event notifies multiple listeners.

Publish–Subscribe (Pub/Sub)

The Observer Pattern is closely related to the Publish–Subscribe (Pub/Sub) pattern.

Observer Pattern

Subject

↓

Observers

Observers know the Subject.

Publish–Subscribe Pattern

Publisher

↓

Event Bus

↓

Subscribers

Publishers and subscribers communicate through an intermediary (event bus), making them even more loosely coupled.

Observer vs Publish–Subscribe

Advantages of Observer Pattern

Loose Coupling

Subjects do not need to know observer implementation details.

Automatic Updates

Observers receive notifications immediately after changes occur.

Scalability

New observers can be added without changing the subject.

Reusability

Observers can be reused across different subjects.

Event-Driven Architecture

Supports responsive and asynchronous applications.

Disadvantages of Observer Pattern

• Large numbers of observers may impact performance.
• Notification order may not be guaranteed.
• Memory leaks can occur if observers are not unsubscribed.
• Debugging notification chains may be difficult.

Real-World Applications

Observer Pattern is commonly used for:

• DOM Event Handling
• Chat Applications
• Weather Applications
• Stock Market Systems
• Notification Systems
• Email Alerts
• SMS Alerts
• Redux State Management
• Vue Reactivity
• RxJS Observables
• WebSocket Applications

When Should You Use Observer Pattern?

Use the Observer Pattern when:

• Multiple objects need updates from one source.
• Building event-driven applications.
• Developing notification systems.
• Managing application state.
• Creating real-time dashboards.

When Should You Avoid Observer Pattern?

Avoid the Observer Pattern when:

• Only one object needs updates.
• The notification overhead outweighs the benefits.
• A simpler callback or direct method call is sufficient.

Best Practices

• Unsubscribe observers when they are no longer needed.
• Keep observer logic lightweight.
• Avoid long chains of notifications.
• Use meaningful event names.
• Consider Pub/Sub for large distributed systems.

Common Mistakes

• Forgetting to remove observers.
• Performing heavy computations inside update methods.
• Creating circular notification loops.
• Using the Observer Pattern for simple one-to-one communication.
• Mixing business logic with notification handling.

Strategy Design Pattern in JavaScript

What is the Strategy Pattern?

The Strategy Pattern is a Behavioral Design Pattern that defines a family of algorithms, encapsulates each one separately, and allows them to be selected dynamically at runtime.

Instead of writing multiple if...else or switch statements, different algorithms are placed into separate strategy classes or objects. The client chooses the required strategy based on the situation.

In simple words,

The Strategy Pattern allows an application to switch between different algorithms without modifying the client code.

Definition

The Strategy Pattern is a design pattern that:

• Encapsulates algorithms into separate classes or objects.
• Allows algorithms to be changed at runtime.
• Eliminates complex conditional statements.
• Promotes flexibility and maintainability.
• Follows the Open/Closed Principle.

Why Do We Need the Strategy Pattern?

Suppose an e-commerce website supports multiple payment methods.

Without the Strategy Pattern:

if(payment=="Credit Card"){

}

else if(payment=="UPI"){

}

else if(payment=="PayPal"){

}

else if(payment=="Net Banking"){

}

As more payment methods are added, the code becomes difficult to maintain.

Instead,

Application

      │

      ▼

Payment Strategy

      │

────────────────────────

│      │      │      │

UPI   Card  PayPal  NetBanking

The application simply selects the required strategy.

Real-World Analogy

Imagine using Google Maps.

You can choose different routes.

Destination

      │

───────────────

│      │      │

Car  Bike  Walking

The destination remains the same.

Only the route changes.

The Strategy Pattern works in the same way.

Characteristics of Strategy Pattern

A Strategy Pattern:

• Encapsulates algorithms.
• Supports interchangeable behavior.
• Promotes loose coupling.
• Eliminates lengthy conditional statements.
• Allows runtime selection.

Components of Strategy Pattern

Context

The Context uses one strategy at a time.

Strategy

Defines the common interface.

Concrete Strategies

Each strategy implements a different algorithm.

Strategy Pattern Workflow

Client

     │

     ▼

Context

     │

Select Strategy

     │

───────────────

│      │      │

UPI  Card  PayPal

     │

     ▼

Execute Algorithm

Example 1: Basic Strategy Pattern

class Car{

    travel(){

        console.log(

        "Travelling by Car"

        );

    }

}

class Bike{

    travel(){

        console.log(

        "Travelling by Bike"

        );

    }

}

class Travel{

    constructor(strategy){

        this.strategy=strategy;

    }

    start(){

        this.strategy.travel();

    }

}

const trip=

new Travel(

new Bike()

);

trip.start();

Output

Travelling by Bike

Explanation

The Travel class does not know how travelling happens.

It simply calls:

this.strategy.travel();

Example 2: Payment Gateway

class CreditCard{

    pay(){

        console.log(

        "Paid using Credit Card"

        );

    }

}

class UPI{

    pay(){

        console.log(

        "Paid using UPI"

        );

    }

}

class PayPal{

    pay(){

        console.log(

        "Paid using PayPal"

        );

    }

}

class Payment{

    constructor(strategy){

        this.strategy=strategy;

    }

    checkout(){

        this.strategy.pay();

    }

}

const payment=

new Payment(

new UPI()

);

payment.checkout();

Output

Paid using UPI

Example 3: Tax Calculator

class GST{

    calculate(amount){

        return amount*0.18;

    }

}

class VAT{

    calculate(amount){

        return amount*0.10;

    }

}

class TaxCalculator{

    constructor(strategy){

        this.strategy=strategy;

    }

    calculate(amount){

        console.log(

        this.strategy.calculate(amount)

        );

    }

}

const tax=

new TaxCalculator(

new GST()

);

tax.calculate(1000);

Output