DEV Community: Arun Teja

Singleton vs Observer Pattern: When and Why to Use Each

Arun Teja — Sun, 11 Jan 2026 15:12:06 +0000

Design patterns are not meant to be memorized—they are meant to be chosen.

Two patterns that are often mentioned together, yet solve very different problems, are the Singleton Pattern and the Observer Pattern. Beginners sometimes confuse them because both are commonly used in global or shared contexts.

In this article, we’ll clearly compare these two patterns, understand what problem each one solves, and learn when to use which.

If you haven’t read them yet, you may want to start here:

Singleton Pattern Explained Simply

Observer Pattern Explained Simply

Why Comparing Singleton and Observer Makes Sense

At first glance, Singleton and Observer may seem unrelated:

One controls how many instances exist
The other controls how objects communicate

However, in real-world systems, these two patterns are often used together, which is why understanding their differences is important.

The key distinction lies in what they are responsible for.

The Core Problem Each Pattern Solves

Singleton Pattern: Object Lifecycle

The Singleton Pattern answers the question:

How many instances of this object should exist?

Its responsibility is:

Controlling object creation
Ensuring a single shared instance
Providing a global access point

It focuses on existence and ownership.

Observer Pattern: Object Communication

The Observer Pattern answers a different question:

How do multiple parts of the system react when something changes?

Its responsibility is:

Managing subscriptions
Notifying observers
Keeping components loosely coupled

It focuses on events and reactions, not creation.

Lifecycle vs Communication (The Key Difference)

This single comparison explains almost everything:

Aspect	Singleton	Observer
Primary concern	Object creation	Object communication
Core question	“How many instances?”	“Who should react?”
Focus	Lifecycle	Events
Relationship	One instance	One-to-many
Coupling	Global access	Loose coupling

If you remember just this table, you’ll rarely confuse the two again.

Code Responsibility Comparison

Singleton Responsibility

A Singleton:

Decides when and how an object is created
Ensures the same instance is reused
Does not handle communication logic by itself

Example responsibilities:

Logger instance
Database connection
Configuration loader

Observer Responsibility

An Observer system:

Manages subscriptions
Decides who gets notified
Does not care how observers are created

Example responsibilities:

Event listeners
UI updates
Notification systems

Can Singleton and Observer Be Used Together?

Yes—very often.

In fact, many real systems combine them naturally.

Example Scenario

A NotificationService exists as a Singleton
Multiple components subscribe to it as Observers
The service publishes events
Observers react independently

Here:

Singleton ensures one notification hub
Observer ensures many listeners

They solve different layers of the problem and complement each other.

When to Use Singleton vs Observer

Use Singleton When:

You need exactly one instance
The object represents a shared resource
Multiple instances would cause conflicts
The concern is global consistency

Use Observer When:

Multiple parts of the system must react to changes
You want to avoid tight coupling
Events should propagate automatically
The system is event-driven

Use Both When:

You have a central service (Singleton)
That service emits events
Multiple independent consumers need updates

This combination is extremely common in real-world applications.

Common Misconceptions

❌ “Singleton notifies observers”

No. Singleton controls instance creation, not notifications.

❌ “Observer is global”

No. Observers are scoped to a subject, not global by default.

❌ “They are alternatives”

They are orthogonal patterns, not replacements for each other.

Decision Cheat Sheet

Ask yourself:

Am I solving an object creation problem?

→ Singleton
Am I solving a notification or event problem?

→ Observer
Do I need one shared service that many things react to?

→ Singleton + Observer

Final Thoughts

The Singleton and Observer patterns solve completely different problems, but they often appear together in well-designed systems.

Singleton brings control
Observer brings flexibility

Understanding what each pattern is responsible for is far more important than memorizing their definitions.

If you choose patterns based on problems, not popularity, your system design will naturally improve.

Series Links

📘 Singleton Pattern Explained Simply
📗 Observer Pattern Explained Simply

Singleton vs Observer Pattern: When and Why to Use Each

Arun Teja — Sun, 11 Jan 2026 15:12:06 +0000

Design patterns are not meant to be memorized—they are meant to be chosen.

In this article, we’ll clearly compare these two patterns, understand what problem each one solves, and learn when to use which.

If you haven’t read them yet, you may want to start here:

Singleton Pattern Explained Simply

Observer Pattern Explained Simply

Why Comparing Singleton and Observer Makes Sense

At first glance, Singleton and Observer may seem unrelated:

One controls how many instances exist
The other controls how objects communicate

However, in real-world systems, these two patterns are often used together, which is why understanding their differences is important.

The key distinction lies in what they are responsible for.

The Core Problem Each Pattern Solves

Singleton Pattern: Object Lifecycle

The Singleton Pattern answers the question:

How many instances of this object should exist?

Its responsibility is:

Controlling object creation
Ensuring a single shared instance
Providing a global access point

It focuses on existence and ownership.

Observer Pattern: Object Communication

The Observer Pattern answers a different question:

How do multiple parts of the system react when something changes?

Its responsibility is:

Managing subscriptions
Notifying observers
Keeping components loosely coupled

It focuses on events and reactions, not creation.

Lifecycle vs Communication (The Key Difference)

This single comparison explains almost everything:

Aspect	Singleton	Observer
Primary concern	Object creation	Object communication
Core question	“How many instances?”	“Who should react?”
Focus	Lifecycle	Events
Relationship	One instance	One-to-many
Coupling	Global access	Loose coupling

If you remember just this table, you’ll rarely confuse the two again.

Code Responsibility Comparison

Singleton Responsibility

A Singleton:

Decides when and how an object is created
Ensures the same instance is reused
Does not handle communication logic by itself

Example responsibilities:

Logger instance
Database connection
Configuration loader

Observer Responsibility

An Observer system:

Manages subscriptions
Decides who gets notified
Does not care how observers are created

Example responsibilities:

Event listeners
UI updates
Notification systems

Can Singleton and Observer Be Used Together?

Yes—very often.

In fact, many real systems combine them naturally.

Example Scenario

A NotificationService exists as a Singleton
Multiple components subscribe to it as Observers
The service publishes events
Observers react independently

Here:

Singleton ensures one notification hub
Observer ensures many listeners

They solve different layers of the problem and complement each other.

When to Use Singleton vs Observer

Use Singleton When:

You need exactly one instance
The object represents a shared resource
Multiple instances would cause conflicts
The concern is global consistency

Use Observer When:

Multiple parts of the system must react to changes
You want to avoid tight coupling
Events should propagate automatically
The system is event-driven

Use Both When:

You have a central service (Singleton)
That service emits events
Multiple independent consumers need updates

This combination is extremely common in real-world applications.

Common Misconceptions

❌ “Singleton notifies observers”

No. Singleton controls instance creation, not notifications.

❌ “Observer is global”

No. Observers are scoped to a subject, not global by default.

❌ “They are alternatives”

They are orthogonal patterns, not replacements for each other.

Decision Cheat Sheet

Ask yourself:

Am I solving an object creation problem?

→ Singleton
Am I solving a notification or event problem?

→ Observer
Do I need one shared service that many things react to?

→ Singleton + Observer

Final Thoughts

The Singleton and Observer patterns solve completely different problems, but they often appear together in well-designed systems.

Singleton brings control
Observer brings flexibility

Understanding what each pattern is responsible for is far more important than memorizing their definitions.

If you choose patterns based on problems, not popularity, your system design will naturally improve.

Series Links

📘 Singleton Pattern Explained Simply
📗 Observer Pattern Explained Simply

Observer Pattern Explained Simply With JavaScript Examples

Arun Teja — Sun, 11 Jan 2026 15:03:46 +0000

Modern applications are highly interactive and event-driven.

When one part of a system changes, many other parts often need to react to that change.

The Observer Pattern exists to solve this exact problem—how to notify multiple parts of a system when something changes, without tightly coupling them together.

In this article, we’ll understand the Observer Pattern using clear explanations, a real-world perspective, and a practical JavaScript example.

Core Values & Definition

Core Value

Loose coupling and reactive communication.

The Observer Pattern focuses on how objects communicate, not how they are created.

It answers an important question:

How can multiple objects react to a change without constantly checking for updates or being tightly linked to each other?

Definition

The Observer Pattern defines a one-to-many relationship where multiple objects (observers) subscribe to another object (subject) and are automatically notified when the subject’s state changes.

In simpler terms:

One object changes
Many others react
No direct dependency between them

Main Features

The key characteristics of the Observer Pattern are:

One Subject maintains a list of observers
Multiple Observers subscribe to the subject
Observers are notified automatically on state change
Observers can be added or removed dynamically
Promotes loose coupling between components

These features make Observer ideal for event-driven systems.

A Real-World Perspective

Think about subscribing to a YouTube channel.

You subscribe to a channel
When the creator uploads a new video, you get notified
You don’t constantly check the channel for updates
You can unsubscribe anytime

The channel doesn’t know who you are—it just notifies all subscribers when something changes.

That’s exactly how the Observer Pattern works:

One subject
Many observers
Automatic notifications
No tight dependencies

Practical Exercise

Scenario: Simple Notification System

Imagine an application where multiple components need to react when a new message arrives:

UI updates
Email notifications
Logging

Hard-coding calls to each component would tightly couple the system and make it difficult to extend.

Observer solves this cleanly.

JavaScript Implementation

class NotificationService {
  constructor() {
    this.subscribers = [];
  }

  subscribe(observer) {
    this.subscribers.push(observer);
  }

  unsubscribe(observer) {
    this.subscribers = this.subscribers.filter(
      sub => sub !== observer
    );
  }

  notify(message) {
    this.subscribers.forEach(sub => sub.update(message));
  }
}

class UserNotifier {
  update(message) {
    console.log("User notified:", message);
  }
}

class EmailNotifier {
  update(message) {
    console.log("Email sent:", message);
  }
}

// Usage
const notificationService = new NotificationService();

const userNotifier = new UserNotifier();
const emailNotifier = new EmailNotifier();

notificationService.subscribe(userNotifier);
notificationService.subscribe(emailNotifier);

notificationService.notify("New message received");

What This Example Demonstrates

One subject manages a list of observers
Observers react automatically when the subject changes
New observers can be added without changing existing logic
Observers remain loosely coupled to the subject
The system becomes flexible and easy to extend

This example highlights the core strength of the Observer Pattern:

changes in one part of the system automatically propagate to others without tight coupling.

Real-World Use Cases

The Observer Pattern is commonly used in:

Event systems (click, scroll, resize)
UI frameworks (React, Angular, Vue)
Real-time dashboards
Notification systems
Chat and messaging applications
State management libraries
Node.js EventEmitter

Whenever something happens and multiple parts of the system need to react, Observer is a natural fit.

How to Identify When to Use Observer

Use the Observer Pattern when:

Multiple components need to react to a single change
You want to avoid tight coupling between components
Observers may be added or removed dynamically
Automatic updates are preferred over manual polling
The system is event-driven by nature

A helpful question to ask:

Do multiple independent parts of my system need to react when something changes?

If the answer is yes, the Observer Pattern is a strong candidate.

When NOT to Use Observer

Avoid the Observer Pattern when:

Only a single consumer exists
Simple function calls are sufficient
Execution order is critical and complex
Too many notifications would add unnecessary overhead

Observer should not replace straightforward communication unnecessarily.

Disadvantages and Trade-offs

Like any design pattern, Observer comes with trade-offs.

Common Issues

Harder debugging due to many observers
Unexpected side effects from poorly designed observers
Memory leaks if observers are not unsubscribed
Notification order may be unpredictable

These issues often surface in large or unstructured systems.

How to Mitigate These Issues

Clearly define observer responsibilities
Always unsubscribe observers when they are no longer needed
Avoid heavy business logic inside observers
Keep event flows simple and well-documented

When used thoughtfully, Observer remains powerful and maintainable.

Final Thoughts

The Observer Pattern is a foundation of modern, reactive software systems.

Used correctly, it enables:

Loose coupling
Scalable communication
Clean event-driven architecture

Used carelessly, it can introduce:

Event sprawl
Debugging complexity
Hidden dependencies

The key is clarity and discipline.

When multiple parts of a system need to react to change without knowing about each other, the Observer Pattern is the right tool.

Singleton Pattern Explained Simply With JavaScript Examples

Arun Teja — Sun, 11 Jan 2026 14:19:29 +0000

Design patterns often feel abstract until we clearly see the problem they solve.

The Singleton Pattern is one of the simplest & important design patterns, yet it is frequently misunderstood and misused.

In this article, we’ll break down the Singleton Pattern using clear explanations, a relatable real-world perspective, and a practical JavaScript example that shows why this pattern exists.

Core Values & Definition

Core Value

Control and consistency.

The Singleton Pattern exists to answer one important question:

How do we ensure that only one instance of an object exists across the entire application?

Some objects represent shared resources. Creating multiple instances of such objects can lead to:

Inconsistent state
Conflicting behavior
Difficult debugging
Unnecessary memory usage

Definition

The Singleton Pattern ensures that a class or object has only one instance and provides a global access point to that instance.

In simpler terms:

Object creation is controlled
Everyone works with the same instance
The application behaves consistently

Main Features

A typical Singleton has the following characteristics:

Single instance throughout the application lifecycle
Global access point to that instance
Controlled creation logic
Shared state across all consumers
Often lazy initialization (created only when needed)

A Real-World Perspective

Think about the music player on your phone.

You can control it from multiple places:

Lock screen
Notification panel
Music app itself

But no matter where you press play or pause, there is only one active music player running in the background.

If your phone created a new music player instance every time you interacted with a control:

Multiple songs would play at once
Volume controls would conflict
The entire experience would break

To avoid this, the system ensures that all controls talk to the same underlying player instance.

That is exactly how the Singleton Pattern works:
one shared instance, accessed from many places, behaving consistently.

Practical Exercise

Scenario: Centralized Application Logger

In real-world applications:

Logs are generated from many different files
Logs should be collected in one place
Log order and consistency are important for debugging

Creating multiple logger instances would:

Fragment logs
Break ordering
Make debugging harder

A logger is a perfect candidate for the Singleton Pattern.

JavaScript Implementation

class Logger {
  constructor() {
    if (Logger.instance) {
      return Logger.instance;
    }

    this.logs = [];
    Logger.instance = this;
  }

  log(message) {
    const entry = `[${new Date().toISOString()}] ${message}`;
    this.logs.push(entry);
    console.log(entry);
  }

  getLogs() {
    return this.logs;
  }
}

// Usage
const logger1 = new Logger();
const logger2 = new Logger();

logger1.log("Application started");
logger2.log("User logged in");

console.log(logger1 === logger2); // true

What This Example Demonstrates

Only one logger instance exists across the application
Logs coming from different parts of the code end up in the same place
Shared state is intentional and meaningful
The need for Singleton is clear and practical, not theoretical

This example shows why Singleton is useful when multiple instances would actively cause problems, not just inconvenience.

Real-World Use Cases

The Singleton Pattern is commonly used for:

Logger services
Database connection managers
Cache managers
Message queue clients (Kafka, RabbitMQ)
Feature flag systems
Application-wide configuration loaders

These are shared infrastructure components that should remain consistent across the entire application.

How to Identify When to Use Singleton

Use the Singleton Pattern when:

You need exactly one instance of an object
The object represents a shared resource
Multiple instances would lead to conflicts or inconsistency
Consistency across the application is critical
Object creation is expensive or resource-heavy

A helpful question to ask yourself is:

Does it make sense for this object to exist more than once?

If the answer is no, Singleton is a strong candidate.

When NOT to Use Singleton

Avoid the Singleton Pattern when:

You need multiple independent instances
Behavior should vary per consumer
Test isolation is important
Global state would increase coupling between modules

Singleton should be used deliberately, not by default.

Disadvantages and Trade-offs

Like any design pattern, Singleton comes with trade-offs.

Common Issues

Behaves like global state
Makes unit testing harder
Introduces hidden dependencies
Can be easily overused or abused

These issues usually arise when Singleton is used outside of infrastructure-level concerns.

How to Mitigate These Issues

Keep Singleton logic minimal and focused
Avoid placing business logic inside Singleton classes
Prefer dependency injection where possible
Use Singleton mainly for shared infrastructure components

Used carefully, these practices reduce the downsides significantly.

Final Thoughts

The Singleton Pattern is neither good nor bad—it is a tool.

Used correctly, it provides:

Order
Consistency
Predictability

Used carelessly, it can introduce:

Tight coupling
Testing complexity
Hidden dependencies

The key is intentional usage.

When a system genuinely needs one and only one instance, the Singleton Pattern is the right choice.

Mastering JavaScript Set Operations: 7 Powerful Methods You Can’t Miss

Arun Teja — Sat, 14 Jun 2025 06:48:40 +0000

TL;DR

Learn how JavaScript’s seven new Set methods—difference, intersection, union, symmetricDifference, isDisjointFrom, isSubsetOf, and isSupersetOf—let you write cleaner, more expressive code.

Introduction

In ES6, the Set object became a staple for storing unique values, but until recently, combining or comparing sets required clunky loops or array conversions. You might have written code like this to get the intersection of two sets:

const intersection = new Set(
  [...setA].filter(x => setB.has(x))
);

Thankfully, JavaScript now includes built-in methods that make these operations concise and self-documenting. In this article, we’ll explore seven powerful Set methods—difference(), intersection(), union(), symmetricDifference(), isDisjointFrom(), isSubsetOf(), and isSupersetOf()—to help you refactor old code and simplify your data-structure logic.

Deep Dive: The 7 New Set Methods

For each method below you’ll see:
1. Signature
2. What it does
3. Example
4. When to use it

1. difference()

Set.prototype.difference(otherSet) → Set

What it does:
Returns a new Set containing all values in the original set that are not in otherSet.
Example

const setA = new Set([1, 2, 3, 4]);
const setB = new Set([3, 4, 5]);
const onlyInA = setA.difference(setB);
console.log(onlyInA); // Set {1, 2}

When to use it Filtering out unwanted values from one collection based on another.

2. intersection()

Set.prototype.intersection(otherSet) → Set

What it does:
Returns a new Set containing only the values found in both sets.
Example

const setA = new Set(['apple', 'banana', 'cherry']);
const setB = new Set(['banana', 'dragonfruit', 'apple']);
const common = setA.intersection(setB);
console.log(common); // Set {'apple', 'banana'}

When to use it Finding overlaps between two datasets (e.g., shared tags, common permissions).

3. union()

Set.prototype.union(otherSet) → Set

What it does:
Returns a new Set containing all unique values from both sets.
Example

const setA = new Set([1, 2]);
const setB = new Set([2, 3, 4]);
const all = setA.union(setB);
console.log(all); // Set {1, 2, 3, 4}

When to use it Merging data streams or combining feature-flag sets.

4. symmetricDifference()

Set.prototype.symmetricDifference(otherSet) → Set

What it does:
Returns a new Set of values that are in either set but not both.
Example

const setA = new Set(['x', 'y', 'z']);
const setB = new Set(['y', 'w']);
const diff = setA.symmetricDifference(setB);
console.log(diff); // Set {'x', 'z', 'w'}

When to use it Identifying elements that differ between two configurations or snapshots.

5. isDisjointFrom()

Set.prototype.isDisjointFrom(otherSet) → boolean

What it does:
Returns true if the two sets share no common elements.
Example

const setA = new Set([10, 20]);
const setB = new Set([30, 40]);
console.log(setA.isDisjointFrom(setB)); // true

const setC = new Set([20, 50]);
console.log(setA.isDisjointFrom(setC)); // false

When to use it Quickly check whether two collections overlap at all (e.g., scheduling conflicts).

6. isSubsetOf()

Set.prototype.isSubsetOf(otherSet) → boolean

What it does:
Returns true if every element in the original set is also in otherSet.
Example

const small = new Set([1, 2]);
const large = new Set([1, 2, 3]);
console.log(small.isSubsetOf(large)); // true

const weird = new Set([2, 4]);
console.log(weird.isSubsetOf(large)); // false

When to use it Validating permission hierarchies or ensuring one dataset is contained in another.

7. isSupersetOf()

Set.prototype.isSupersetOf(otherSet) → boolean

What it does:
Returns true if the original set contains every element of otherSet.
Example

const roles = new Set(['admin', 'editor', 'viewer']);
const needed = new Set(['editor', 'viewer']);
console.log(roles.isSupersetOf(needed)); // true

const extra = new Set(['editor', 'contributor']);
console.log(roles.isSupersetOf(extra)); // false

When to use it Checking that a user’s permissions include all required rights for a given action.

Practical Use Cases

1.De-duplicating Combined Data Sources
When you merge results from multiple APIs or database queries, you often need to remove duplicates. Instead of mapping to arrays and back, use union() directly:

const apiA = new Set(await fetchUsersFromServiceA());
const apiB = new Set(await fetchUsersFromServiceB());
const uniqueUsers = apiA.union(apiB);

2.Permission and Role Checks
Model user roles or feature toggles as sets, then use isSupersetOf() to verify access:

const userRoles = new Set(['reader', 'commenter']);
const required   = new Set(['reader']);
if (!userRoles.isSupersetOf(required)) {
  throw new Error('Insufficient permissions');
}

3.Comparing Configurations or Feature Flags
Quickly detect what settings have changed between two snapshots using symmetricDifference():

const oldFlags = new Set(['beta', 'darkMode']);
const newFlags = new Set(['darkMode', 'logging']);
const changed  = oldFlags.symmetricDifference(newFlags);
console.log(changed); // Set {'beta', 'logging'}

4.Filtering Out Unwanted Items
Remove deprecated IDs or blacklisted entries with difference():

const allItems     = new Set(getAllItemIds());
const deprecated   = new Set(getDeprecatedIds());
const activeItems  = allItems.difference(deprecated);

5.Overlap and Conflict Detection
Use isDisjointFrom() to verify that two schedules, seat assignments, or resource pools don’t collide:

const morningSlots = new Set(['09:00', '10:00', '11:00']);
const bookedSlots  = new Set(['11:00', '12:00']);
if (!morningSlots.isDisjointFrom(bookedSlots)) {
  console.log('Conflict at 11:00');
}

Conclusion

JavaScript’s new Set methods—difference(), intersection(), union(), symmetricDifference(), isDisjointFrom()
, isSubsetOf(), and isSupersetOf()—turn once-verbose patterns into clear, intent-driven calls.

Now that these operations are part of the language, it’s a great time to:

Revisit your old code that relied on array hacks or manual loops
Refactor your data-handling logic to use these self-documenting methods
Share your favorite use cases and tips in the comments below!

Vim Tabs

Arun Teja — Mon, 26 Jul 2021 19:06:19 +0000

Just like any edit, we open can open multiples files as tab in vim as well. Let's see how it is done.

As usual open a file in vim as vim index.html after the file is opened, from command mode enter :tabedit nameOfTheFile, you want open in an other tab. This way we can open as many files we want.

Example:
   :tabedit style.css
   :tabedit script.js

Or their as another alternative way to open multiple files in tab
vim -p firstFileName secondFileName thirdFileName...

Example:
    vim -p index.html style.css script.js

After opening multiple files in tabs, to navigate among them we use gt command.

gt will take us to the next tab
gT will take us to the previous tab
Or we can also got a specific tab, by providing the tab number
Example:
    2gt will take us to the second tab.

:quitall in command mode, closes all the tabs & vim as well.

That's it for today, It's just introduction to the tabs in vim. If have missed anything or you wanted to add anything, please feel free comment them below. Thanks for reading.