Object-Oriented Programming

Objects are the most important data structure in JavaScript. Almost everything in JS is an object or behaves like one. In simple language, an object is just a collection of key-value pairs — we call them properties. When a property’s value is a function, we call it a method.

Creating objects (object literals)

The simplest way to create an object is with curly braces. This is called an object literal:

const user = {
  name: "Manish",
  age: 25,
  greet() {          // shorthand method syntax
    console.log(`Hi, I'm ${this.name}`);
  }
};

That’s it. No class needed, no constructor — just a plain object.

Dot notation vs bracket notation

We have two ways to access properties:

console.log(user.name);      // "Manish" — dot notation
console.log(user["name"]);   // "Manish" — bracket notation

Dot notation is cleaner, but bracket notation is more powerful — we can use variables and strings with spaces or special characters:

const key = "age";
console.log(user[key]);      // 25 — dynamic access

const weird = { "full name": "Manish P" };
console.log(weird["full name"]); // bracket notation is required here

Computed property names

ES6 lets us use expressions as property names inside the object literal using square brackets:

const field = "email";
const profile = {
  [field]: "manish@example.com",       // key becomes "email"
  [`${field}Verified`]: true           // key becomes "emailVerified"
};

Shorthand syntax

When the variable name matches the property name, we can skip the colon:

const name = "Manish";
const age = 25;

const user = { name, age }; // same as { name: name, age: age }

Object.keys, Object.values, Object.entries

These three static methods are super handy for iterating over objects:

const car = { brand: "Toyota", year: 2022, color: "white" };

Object.keys(car);    // ["brand", "year", "color"]
Object.values(car);  // ["Toyota", 2022, "white"]
Object.entries(car); // [["brand", "Toyota"], ["year", 2022], ["color", "white"]]

Object.entries is especially useful with for...of loops or when we want to convert an object into a Map.

Object.freeze vs Object.seal

Both lock down an object, but in different ways:

• Object.freeze() — no adding, removing, or modifying properties. The object becomes completely immutable (shallow).
• Object.seal() — no adding or removing properties, but we can modify existing ones.

const frozen = Object.freeze({ x: 1 });
frozen.x = 99;     // silently fails (or throws in strict mode)
console.log(frozen.x); // 1

const sealed = Object.seal({ x: 1 });
sealed.x = 99;     // this works!
sealed.y = 2;      // silently fails — can't add new properties
console.log(sealed.x); // 99

One gotcha — both are shallow. Nested objects inside a frozen object can still be modified.

Object.assign

Object.assign copies properties from one or more source objects into a target object. It’s commonly used for merging objects or creating shallow copies:

const defaults = { theme: "dark", lang: "en" };
const userPrefs = { lang: "hi" };

const config = Object.assign({}, defaults, userPrefs);
console.log(config); // { theme: "dark", lang: "hi" }

These days, most of us prefer the spread operator { ...defaults, ...userPrefs } — it does the same thing and looks cleaner.

Checking if a property exists

We have two common approaches:

The in operator checks the object and its entire prototype chain:

const user = { name: "Manish" };
console.log("name" in user);     // true
console.log("toString" in user); // true — inherited from Object.prototype

hasOwnProperty() only checks the object’s own properties (not inherited ones):

console.log(user.hasOwnProperty("name"));     // true
console.log(user.hasOwnProperty("toString")); // false — it's inherited

The modern alternative is Object.hasOwn(obj, prop) which does the same thing as hasOwnProperty but works even if the object doesn’t have that method in its prototype.

Deleting properties

We can remove a property with the delete operator:

const obj = { a: 1, b: 2 };
delete obj.b;
console.log(obj); // { a: 1 }

delete returns true if the deletion succeeds. It doesn’t affect the prototype chain — only own properties.

In simple language, objects are just bags of key-value pairs. We create them with {}, access properties with dot or bracket notation, and use built-in methods like Object.keys(), Object.freeze(), and Object.assign() to work with them. Master these basics, and everything else in JavaScript OOP builds on top of this.

Before ES6 classes existed, constructor functions were the way to create multiple objects with the same shape. Think of a constructor function like a blueprint — we write it once and stamp out as many objects as we need.

A constructor function is just a regular function, but we follow two conventions:

1. The name starts with a capital letter (like Person, Car, User).
2. We call it with the new keyword.

function Person(name, age) {
  this.name = name;
  this.age = age;
  this.greet = function () {
    console.log(`Hi, I'm ${this.name}`);
  };
}

const manish = new Person("Manish", 25);
manish.greet(); // "Hi, I'm Manish"

The 4 steps new performs

When we write new Person("Manish", 25), JavaScript does four things behind the scenes:

1. Creates an empty object — {}
2. Sets the prototype — links the new object’s [[Prototype]] to Person.prototype
3. Calls the function with this bound to the new object
4. Returns the object — if the function doesn’t explicitly return an object, JavaScript returns the newly created one

Here’s what that looks like if we did it manually:

// What "new Person('Manish', 25)" does under the hood:
const obj = {};                              // Step 1
Object.setPrototypeOf(obj, Person.prototype); // Step 2
Person.call(obj, "Manish", 25);              // Step 3
// Step 4: return obj (automatically)

Understanding these 4 steps is crucial — it explains why this works inside constructors and how prototype inheritance is set up.

What happens if we forget new?

If we call a constructor function without new, this will point to the global object (or be undefined in strict mode). That means properties get attached to the wrong place:

const oops = Person("Manish", 25); // forgot new!
console.log(oops);        // undefined (no return value)
console.log(window.name);  // "Manish" — leaked to global!

This is a common bug. ES6 classes fix this by throwing an error if we forget new.

Return value from constructors

If a constructor explicitly returns a primitive (string, number, etc.), JavaScript ignores it and returns the this object anyway. But if it returns an object, that object replaces this:

function Weird() {
  this.name = "original";
  return { name: "replaced" }; // returning an object overrides this
}
const w = new Weird();
console.log(w.name); // "replaced"

function Normal() {
  this.name = "original";
  return 42; // primitive return is ignored
}
const n = new Normal();
console.log(n.name); // "original"

instanceof

instanceof checks whether an object was created by a particular constructor (more precisely, whether the constructor’s .prototype exists in the object’s prototype chain):

const manish = new Person("Manish", 25);

console.log(manish instanceof Person); // true
console.log(manish instanceof Object); // true (everything inherits from Object)
console.log(manish instanceof Array);  // false

Factory functions vs constructors

A factory function is just a regular function that returns an object. No new keyword, no this:

function createPerson(name, age) {
  return {
    name,
    age,
    greet() {
      console.log(`Hi, I'm ${name}`); // closure, not this
    }
  };
}

const user = createPerson("Manish", 25);

The main trade-off: factory functions give us true privacy through closures, but constructor functions let us share methods via the prototype (more memory efficient). In modern JS, most people use classes (which are constructor functions under the hood) and #private fields for privacy.

In simple language, a constructor function is a blueprint for creating objects. The new keyword does the heavy lifting — it creates an empty object, sets up the prototype link, runs the function, and returns the result. Understanding these 4 steps is the key to understanding how JavaScript’s object system works.

JavaScript doesn’t have classical inheritance like Java or C++. Instead, it uses something called prototypal inheritance — objects inherit directly from other objects. This is one of the most important concepts in JS, and once it clicks, a lot of confusing behavior suddenly makes sense.

Every object has a prototype

Every object in JavaScript has a hidden internal link called [[Prototype]]. It points to another object — the object’s prototype. When we try to access a property that doesn’t exist on the object, JavaScript follows this link and looks for the property on the prototype. If it’s not there either, it goes to the prototype’s prototype, and so on. This chain of lookups is the prototype chain.

__proto__ vs .prototype

This is where most people get confused. Let’s clear it up:

• __proto__ (or [[Prototype]]) exists on every object. It’s the actual link to the object’s prototype. We should use Object.getPrototypeOf(obj) instead of __proto__ directly (it’s deprecated but still works).
• .prototype exists only on functions. It’s the object that will become the [[Prototype]] of instances created with new.

function Person(name) {
  this.name = name;
}

const manish = new Person("Manish");

// manish.__proto__ === Person.prototype  (true)
// Person.prototype is the blueprint for instances
console.log(Object.getPrototypeOf(manish) === Person.prototype); // true

Think of it like this: Person.prototype is a stencil. When we use new Person(), the new object’s __proto__ gets pointed at that stencil.

How the prototype chain lookup works

When we access a property on an object, JavaScript does the following:

1. Check the object itself — is the property there? If yes, use it.
2. If not, check object.__proto__ (i.e., the prototype).
3. If still not found, check object.__proto__.__proto__.
4. Keep going until we hit null (end of the chain).
5. If the property isn’t found anywhere, return undefined.

function Animal(type) {
  this.type = type;
}
Animal.prototype.speak = function () {
  return `${this.type} makes a sound`;
};

const dog = new Animal("Dog");

console.log(dog.type);     // "Dog" — found on dog itself
console.log(dog.speak());  // "Dog makes a sound" — found on Animal.prototype
console.log(dog.toString()); // "[object Object]" — found on Object.prototype

Object.create()

Object.create() creates a new object with a specific prototype. It’s the cleanest way to set up prototype-based inheritance without constructor functions:

const parent = {
  greet() {
    return `Hello, I'm ${this.name}`;
  }
};

const child = Object.create(parent); // child's [[Prototype]] is parent
child.name = "Manish";
console.log(child.greet()); // "Hello, I'm Manish"

We can also create an object with no prototype at all:

const bare = Object.create(null);
console.log(bare.toString); // undefined — no Object.prototype methods!

Property shadowing

When we set a property on an object that already exists on its prototype, the new property shadows (hides) the prototype’s version. The prototype property is still there — it’s just not reachable through this object anymore.

function Car(brand) {
  this.brand = brand;
}
Car.prototype.honk = function () { return "Beep!"; };

const myCar = new Car("Toyota");
console.log(myCar.honk()); // "Beep!" — from prototype

myCar.honk = function () { return "HONK!"; }; // shadows the prototype method
console.log(myCar.honk()); // "HONK!" — own property now

delete myCar.honk; // remove the shadow
console.log(myCar.honk()); // "Beep!" — prototype method is back

hasOwnProperty vs in

• in checks the entire prototype chain
• hasOwnProperty() (or the modern Object.hasOwn()) checks only the object’s own properties

const obj = Object.create({ inherited: true });
obj.own = true;

console.log("own" in obj);       // true
console.log("inherited" in obj); // true

console.log(obj.hasOwnProperty("own"));       // true
console.log(obj.hasOwnProperty("inherited")); // false

End of the chain

The prototype chain always ends at Object.prototype, whose own [[Prototype]] is null:

console.log(Object.getPrototypeOf(Object.prototype)); // null

When JavaScript reaches null, the lookup stops. If the property wasn’t found anywhere in the chain, we get undefined.

In simple language, the prototype chain is how JavaScript shares behavior between objects. When we look up a property, JS walks up the chain of linked objects until it finds what it’s looking for (or hits null). Every object is linked to a prototype, and that’s how methods like toString() magically work on every object even though we never defined them.

ES6 classes are one of those features that make JavaScript feel more like a “traditional” OOP language. But here’s the thing — classes in JavaScript are just syntactic sugar over the prototype system. Under the hood, they work exactly like constructor functions and prototypes. The class keyword just gives us a cleaner, more familiar syntax.

Basic class syntax

class Person {
  constructor(name, age) {
    this.name = name;    // instance property
    this.age = age;
  }

  greet() {              // instance method (goes on prototype)
    return `Hi, I'm ${this.name}`;
  }
}

const manish = new Person("Manish", 25);
console.log(manish.greet()); // "Hi, I'm Manish"

The constructor method runs automatically when we call new Person(...). Methods we define inside the class body (like greet) go on Person.prototype, not on each instance — so they’re shared, just like with constructor functions.

Classes are just functions

This is worth proving to ourselves:

console.log(typeof Person); // "function"
console.log(Person.prototype.greet); // [Function: greet]

A class is literally a function. The constructor becomes the function body, and class methods become prototype methods. So class Person { ... } is essentially doing the same thing as defining a constructor function and attaching methods to its prototype.

Static methods and properties

Static members belong to the class itself, not to instances. We use the static keyword:

class MathHelper {
  static PI = 3.14159;

  static square(x) {
    return x * x;
  }
}

console.log(MathHelper.PI);         // 3.14159
console.log(MathHelper.square(5));  // 25

// const m = new MathHelper();
// m.square(5);  // TypeError — static methods aren't on instances

Think of static methods like utility functions that are related to the class but don’t need an instance. Array.isArray(), Object.keys(), Number.isNaN() — all static methods.

Class expressions

Just like functions, classes can be expressions too:

const Animal = class {
  constructor(type) {
    this.type = type;
  }
};

// Named class expression
const Vehicle = class Car {
  // "Car" is only accessible inside this class body
};

Class expressions are less common, but they come in handy when we need to dynamically create classes or pass them around.

Class hoisting (TDZ)

This is a key difference from function declarations. Classes are NOT hoisted like functions. They sit in the Temporal Dead Zone (TDZ) just like let and const:

// const p = new Person(); // ReferenceError!

class Person {
  constructor() {
    this.name = "Manish";
  }
}

const p = new Person(); // works here

With function declarations, we can call them before the line they’re declared on. With classes, we can’t. We must define the class before using it.

Must use new

Unlike constructor functions, classes cannot be called without new. JavaScript throws an error:

// Person("Manish"); // TypeError: Class constructor Person cannot be invoked without 'new'
const p = new Person("Manish"); // correct

This is actually a nice safety feature — remember how forgetting new with constructor functions silently messes up this? Classes prevent that.

Class fields (public instance fields)

We can declare properties directly in the class body without putting them in the constructor:

class Counter {
  count = 0;       // public field — each instance gets its own copy

  increment() {
    this.count++;
  }
}

const c = new Counter();
c.increment();
console.log(c.count); // 1

Class fields are defined on the instance, not on the prototype. They run at the beginning of the constructor (or when super() returns in subclasses).

Methods are non-enumerable

One subtle difference from manually attaching methods to a prototype — class methods are non-enumerable. This means they won’t show up in for...in loops or Object.keys():

class Dog {
  bark() { return "Woof!"; }
}

const d = new Dog();
console.log(Object.keys(d)); // [] — bark is not enumerable

This is actually the correct behavior. We usually don’t want methods to show up when we iterate over an object’s properties.

Putting it all together

Here’s a practical example that uses most of what we’ve covered:

class User {
  static count = 0;  // static field

  constructor(name, role) {
    this.name = name;
    this.role = role;
    User.count++;     // track how many users were created
  }

  describe() {
    return `${this.name} (${this.role})`;
  }

  static totalUsers() {
    return `Total users: ${User.count}`;
  }
}

const u1 = new User("Manish", "admin");
const u2 = new User("Priya", "editor");
console.log(u1.describe());      // "Manish (admin)"
console.log(User.totalUsers());  // "Total users: 2"

In simple language, ES6 classes are a nicer way to write constructor functions and prototype methods. They don’t introduce a new inheritance model — they just make the existing prototype system easier to read and write. Under the hood, typeof MyClass is still "function", and methods still live on the prototype.

Inheritance lets us create a new class based on an existing one. The child class gets all the properties and methods of the parent, and can add its own or override what it inherited. In JavaScript, we use extends to set up this relationship and super to talk to the parent.

Basic inheritance with extends

class Animal {
  constructor(name) {
    this.name = name;
  }

  speak() {
    return `${this.name} makes a sound`;
  }
}

class Dog extends Animal {
  bark() {
    return `${this.name} says Woof!`;
  }
}

const rex = new Dog("Rex");
console.log(rex.speak()); // "Rex makes a sound" — inherited from Animal
console.log(rex.bark());  // "Rex says Woof!" — own method

Dog inherits everything from Animal. We didn’t define a constructor in Dog, so JavaScript automatically calls the parent’s constructor for us.

super() in the constructor

When a child class has its own constructor, we must call super() before using this. This calls the parent’s constructor and sets up the instance properly:

class Animal {
  constructor(name) {
    this.name = name;
  }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name);        // MUST call super() first!
    this.breed = breed; // now we can use this
  }
}

const rex = new Dog("Rex", "German Shepherd");
console.log(rex.name);  // "Rex"
console.log(rex.breed); // "German Shepherd"

If we forget super() or try to use this before calling it, JavaScript throws a ReferenceError. This is a hard rule — no exceptions.

Method overriding

A child class can define a method with the same name as the parent’s method. This is called method overriding — the child’s version replaces the parent’s for instances of the child class:

class Animal {
  speak() {
    return "Some generic sound";
  }
}

class Cat extends Animal {
  speak() {
    return "Meow!"; // overrides Animal's speak()
  }
}

const cat = new Cat();
console.log(cat.speak()); // "Meow!" — child's version wins

super.method() for parent method calls

Sometimes we don’t want to completely replace the parent’s method — we want to extend it. We can call the parent’s version using super.methodName():

class Animal {
  speak() {
    return "Some sound";
  }

  describe() {
    return `I am a ${this.constructor.name}`;
  }
}

class Dog extends Animal {
  speak() {
    const parentResult = super.speak(); // call parent's speak
    return `${parentResult}... actually, Woof!`;
  }
}

const d = new Dog();
console.log(d.speak()); // "Some sound... actually, Woof!"

Class hierarchy diagram

Here’s how a typical class hierarchy looks with prototype links:

Inheriting static methods

Static methods are inherited too! The child class can access the parent’s static methods:

class Animal {
  static kingdom() {
    return "Animalia";
  }
}

class Dog extends Animal {}

console.log(Dog.kingdom()); // "Animalia" — inherited static method

This works because Dog.__proto__ === Animal (the class itself, not the prototype). Static methods live on the constructor function, and the child constructor’s prototype points to the parent constructor.

instanceof with inheritance

instanceof walks up the prototype chain, so it returns true for the child class and all its ancestors:

const rex = new Dog("Rex", "Lab");

console.log(rex instanceof Dog);    // true
console.log(rex instanceof Animal); // true
console.log(rex instanceof Object); // true

Multi-level inheritance

We can chain inheritance as deep as we want, but in practice, going more than 2-3 levels deep usually means we should rethink our design (favor composition over deep inheritance):

class Animal {
  constructor(name) { this.name = name; }
  eat() { return `${this.name} eats`; }
}

class Dog extends Animal {
  bark() { return `${this.name} barks`; }
}

class GuideDog extends Dog {
  constructor(name, handler) {
    super(name);
    this.handler = handler;
  }
  guide() { return `${this.name} guides ${this.handler}`; }
}

const buddy = new GuideDog("Buddy", "Alex");
console.log(buddy.eat());   // "Buddy eats" — from Animal
console.log(buddy.bark());  // "Buddy barks" — from Dog
console.log(buddy.guide()); // "Buddy guides Alex" — own method

Common pitfall: forgetting super()

This is the number one mistake beginners make. If our child class has a constructor, we must call super() before doing anything with this:

class Child extends Parent {
  constructor() {
    // this.x = 10; // ReferenceError! Must call super() first
    super();
    this.x = 10;    // now it's fine
  }
}

The reason is that this doesn’t exist in the child constructor until super() creates it. This is by design — it ensures the parent gets to initialize the object first.

In simple language, extends tells JavaScript “this class is based on that class”, and super is how the child talks to the parent. super() in the constructor calls the parent’s constructor, and super.method() calls the parent’s version of a method. Together they give us clean, readable class hierarchies.

Encapsulation means hiding the internal details of an object and only exposing what’s necessary. Think of it like a car — we use the steering wheel and pedals (public interface) without needing to know how the engine works internally (private details).

In many languages, we get private, protected, and public keywords. JavaScript didn’t have real privacy for a long time, so developers came up with creative workarounds. Now, with ES2022, we finally have native private fields using the # syntax.

The # private fields (ES2022)

This is the modern, official way to create truly private properties. We prefix the name with #:

class BankAccount {
  #balance = 0;        // private field

  constructor(initial) {
    this.#balance = initial;
  }

  deposit(amount) {
    this.#balance += amount;
  }

  getBalance() {
    return this.#balance; // accessible inside the class
  }
}

const acc = new BankAccount(100);
acc.deposit(50);
console.log(acc.getBalance()); // 150
// console.log(acc.#balance);  // SyntaxError! Can't access from outside

The # is part of the field name — #balance and balance are two completely different properties. Trying to access #balance from outside the class body is a SyntaxError, not a runtime error. The privacy is enforced by the engine itself.

Private methods

We can make methods private too:

class User {
  #password;

  constructor(name, password) {
    this.name = name;
    this.#password = password;
  }

  #encrypt(value) {         // private method
    return btoa(value);     // simple encoding for demo
  }

  getEncryptedPassword() {
    return this.#encrypt(this.#password);
  }
}

const u = new User("Manish", "secret123");
console.log(u.getEncryptedPassword()); // "c2VjcmV0MTIz"
// u.#encrypt("test");  // SyntaxError!

Private static fields

Static fields can be private too — useful for things like instance counts or shared secrets:

class Connection {
  static #maxConnections = 5;
  static #activeCount = 0;

  constructor() {
    if (Connection.#activeCount >= Connection.#maxConnections) {
      throw new Error("Too many connections");
    }
    Connection.#activeCount++;
  }

  static getActiveCount() {
    return Connection.#activeCount;
  }
}

Closure-based privacy (pre-ES2022)

Before # fields existed, closures were the go-to pattern for privacy. The idea is that variables declared inside a function are only accessible within that function’s scope:

function createUser(name, password) {
  // password is truly private — it's a closure variable
  return {
    name,
    checkPassword(input) {
      return input === password;
    }
  };
}

const user = createUser("Manish", "secret");
console.log(user.name);              // "Manish"
console.log(user.checkPassword("secret")); // true
console.log(user.password);          // undefined — not accessible

This still works great, but the downside is that we can’t use it with class syntax, and methods aren’t shared on the prototype (each instance gets its own copy).

WeakMap for private data

Another pre-ES2022 pattern uses a WeakMap to store private data keyed by the instance:

const _data = new WeakMap();

class User {
  constructor(name, secret) {
    _data.set(this, { secret }); // store private data
    this.name = name;
  }

  getSecret() {
    return _data.get(this).secret;
  }
}

const u = new User("Manish", "hidden");
console.log(u.getSecret()); // "hidden"
console.log(u.secret);      // undefined

The WeakMap is defined outside the class, so it’s not accessible to consumers. And because it’s a weak map, the entries are garbage-collected when the instance is garbage-collected. Clever, but now that we have # fields, there’s rarely a reason to use this pattern.

The _underscore convention

This is the oldest approach — just prefix the property with an underscore to signal “hey, don’t touch this from outside”:

class Config {
  constructor() {
    this._apiKey = "abc123"; // convention: treat as private
  }
}

But it’s not real privacy. Anyone can still access config._apiKey. It’s just a naming convention, a gentleman’s agreement. We see it a lot in older codebases and some libraries.

Symbols as pseudo-private keys

Using Symbol as property keys makes properties hard to access accidentally (they won’t show up in Object.keys or for...in), but they’re not truly private — someone can still find them with Object.getOwnPropertySymbols():

const _secret = Symbol("secret");

class Vault {
  constructor(value) {
    this[_secret] = value;
  }

  reveal() {
    return this[_secret];
  }
}

const v = new Vault("treasure");
console.log(v.reveal()); // "treasure"
// console.log(v[_secret]); // only works if you have the Symbol reference

Comparison of approaches

In simple language, encapsulation is about hiding the stuff that the outside world doesn’t need to see. In modern JavaScript, use # private fields — they’re simple, enforced by the engine, and work perfectly with classes. The older patterns (closures, WeakMap, underscores, Symbols) are good to know for reading legacy code, but for new code, # is the way to go.

Polymorphism is a fancy word for a simple idea: same interface, different behavior. We call the same method on different objects, and each one responds in its own way. In simple language, polymorphism means “many forms” — the same action can look different depending on who’s doing it.

Languages like Java have strict polymorphism through interfaces and abstract classes. JavaScript takes a more relaxed approach — we get polymorphism through method overriding and duck typing, without needing formal interfaces.

Method overriding (runtime polymorphism)

This is the most common form of polymorphism in JS. A child class overrides a method from the parent, so calling the same method on different instances produces different results:

class Shape {
  area() {
    return 0;
  }
}

class Circle extends Shape {
  constructor(radius) { super(); this.radius = radius; }
  area() { return Math.PI * this.radius ** 2; }
}

class Rectangle extends Shape {
  constructor(w, h) { super(); this.w = w; this.h = h; }
  area() { return this.w * this.h; }
}

Now we can write code that works with any shape without caring about the specific type:

const shapes = [new Circle(5), new Rectangle(4, 6)];

shapes.forEach(shape => {
  console.log(shape.area()); // each shape calculates its own area
});
// 78.54  (circle)
// 24     (rectangle)

This is the power of polymorphism — the forEach loop doesn’t know or care whether it’s a circle or rectangle. It just calls .area() and trusts each object to do the right thing.

Duck typing

JavaScript doesn’t have interfaces or type checking at runtime (unless we add it ourselves). Instead, it follows a philosophy called duck typing: “If it walks like a duck and quacks like a duck, it’s a duck.”

In simple language, we don’t check what an object is — we check what it can do. If it has the method we need, we call it. Doesn’t matter if it’s a class instance, a plain object, or anything else:

class Duck {
  quack() { return "Quack!"; }
}

class Person {
  quack() { return "I'm pretending to quack!"; }
}

const fakeQuacker = { quack: () => "Rubber ducky!" };

function makeItQuack(thing) {
  // We don't check if thing is a Duck
  // We just check if it can quack
  if (typeof thing.quack === "function") {
    console.log(thing.quack());
  }
}

makeItQuack(new Duck());     // "Quack!"
makeItQuack(new Person());   // "I'm pretending to quack!"
makeItQuack(fakeQuacker);    // "Rubber ducky!"

All three objects work because they all have a quack() method. That’s duck typing in action.

toString() and valueOf() overriding

Every object in JavaScript inherits toString() and valueOf() from Object.prototype. We can override them to control how our objects behave in string and numeric contexts:

class Money {
  constructor(amount, currency) {
    this.amount = amount;
    this.currency = currency;
  }

  toString() {
    return `${this.currency} ${this.amount.toFixed(2)}`;
  }

  valueOf() {
    return this.amount;
  }
}

const price = new Money(49.99, "USD");
console.log(`Price: ${price}`);    // "Price: USD 49.99" — calls toString()
console.log(price + 10);           // 59.99 — calls valueOf()

This is polymorphism too — the same operators (+, template literals) produce different results depending on what toString() and valueOf() return.

Symbol.toPrimitive

Symbol.toPrimitive gives us even more control. It’s a method that JavaScript calls when it needs to convert an object to a primitive. It receives a hint — either "string", "number", or "default":

class Temperature {
  constructor(celsius) {
    this.celsius = celsius;
  }

  [Symbol.toPrimitive](hint) {
    if (hint === "string") return `${this.celsius}°C`;
    if (hint === "number") return this.celsius;
    return this.celsius; // default
  }
}

const temp = new Temperature(36.6);
console.log(`Body temp: ${temp}`); // "Body temp: 36.6°C" (string hint)
console.log(temp + 0);             // 36.6 (number hint)

When Symbol.toPrimitive is defined, it takes priority over toString() and valueOf().

Symbol.hasInstance

Symbol.hasInstance lets us customize how instanceof works. This is a more advanced form of polymorphism — we’re changing how the type-checking mechanism itself behaves:

class EvenNumber {
  static [Symbol.hasInstance](value) {
    return typeof value === "number" && value % 2 === 0;
  }
}

console.log(4 instanceof EvenNumber);  // true
console.log(7 instanceof EvenNumber);  // false
console.log("hello" instanceof EvenNumber); // false

We’ve redefined what it means to be an “instance” of EvenNumber. Now instanceof doesn’t check the prototype chain — it runs our custom logic instead.

Ad-hoc polymorphism through operator context

JavaScript operators behave differently depending on the types of their operands. The + operator is the classic example:

console.log(5 + 3);       // 8 — numeric addition
console.log("5" + 3);     // "53" — string concatenation
console.log(true + true);  // 2 — boolean to number coercion

This isn’t something we design — it’s built into the language. But when we override toString(), valueOf(), or Symbol.toPrimitive, we’re plugging into this ad-hoc polymorphism and deciding how our objects behave with these operators.

Practical example: a pluggable logger

Here’s a real-world use of polymorphism. Different loggers implement the same interface, and we can swap them out without changing the code that uses them:

class ConsoleLogger {
  log(msg) { console.log(`[CONSOLE] ${msg}`); }
}

class FileLogger {
  log(msg) { console.log(`[FILE] Writing: ${msg}`); }
}

class SilentLogger {
  log(msg) { /* do nothing */ }
}

function processOrder(order, logger) {
  logger.log(`Processing order #${order.id}`);
  // ... business logic
  logger.log(`Order #${order.id} complete`);
}

// Swap loggers without changing processOrder
processOrder({ id: 42 }, new ConsoleLogger());
processOrder({ id: 43 }, new SilentLogger());

This is polymorphism and duck typing working together. processOrder doesn’t care which logger it gets — it just needs something with a .log() method.

In simple language, polymorphism in JavaScript means we can call the same method on different objects and get different results. We achieve this through method overriding (class hierarchies) and duck typing (if it has the method, just call it). Unlike strict languages, JavaScript doesn’t need interfaces or type declarations — if the method exists, it works.

Abstraction is about hiding the messy details and showing only what matters. Think of it like driving a car — we use the steering wheel and pedals, but we don’t need to know how the engine combustion works internally. In OOP, abstraction means we expose a clean interface and tuck away the complexity behind it.

Why Abstraction Matters

Without abstraction, every part of our code knows about every other part’s internals. One small change breaks everything. Abstraction gives us:

• Simpler usage — callers only see what they need
• Easier maintenance — we can change internals without breaking consumers
• Enforced contracts — subclasses must implement certain methods

JS Has No abstract Keyword

Languages like Java and TypeScript have abstract classes that can’t be instantiated directly and force subclasses to implement certain methods. JavaScript doesn’t have this built-in. But we can fake it.

The trick is to throw an error in the base class method. If a subclass forgets to override it, the error tells them immediately.

class PaymentProcessor {
  process(amount) {
    throw new Error("Subclass must implement process()"); // enforce the contract
  }
  refund(transactionId) {
    throw new Error("Subclass must implement refund()");
  }
}

class StripeProcessor extends PaymentProcessor {
  process(amount) {
    console.log(`Charging $${amount} via Stripe`);
  }
  refund(transactionId) {
    console.log(`Refunding ${transactionId} via Stripe`);
  }
}

If someone creates a PaypalProcessor but forgets to implement refund(), they’ll get a clear error the first time it’s called. Not perfect, but it works.

Preventing Direct Instantiation

We can also stop anyone from creating an instance of the base class directly using new.target:

class Shape {
  constructor() {
    if (new.target === Shape) {
      throw new Error("Shape is abstract — use a subclass instead");
    }
  }
  area() {
    throw new Error("Subclass must implement area()");
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }
  area() {
    return Math.PI * this.radius ** 2;
  }
}

// new Shape();        // Error: Shape is abstract
// new Circle(5).area() // 78.54

new.target tells us which constructor was actually called. If someone does new Shape() directly, new.target is Shape. If they do new Circle(5), new.target is Circle even though Shape’s constructor runs.

Factory Functions as Abstraction

Factory functions are one of the cleanest abstraction patterns in JS. The caller doesn’t know (or care) what’s happening inside — they just get an object back.

function createLogger(type) {
  if (type === "console") {
    return { log: (msg) => console.log(`[LOG] ${msg}`) };
  }
  if (type === "silent") {
    return { log: () => {} }; // does nothing, same interface
  }
  throw new Error(`Unknown logger type: ${type}`);
}

const logger = createLogger("console");
logger.log("Server started"); // [LOG] Server started

The caller just calls createLogger() and gets something with a .log() method. It doesn’t care whether it’s writing to the console, a file, or nowhere. That’s abstraction.

Symbol.species — Controlling Derived Constructors

When we extend built-in classes like Array, methods like .map() and .filter() return an instance of our subclass by default. Symbol.species lets us control this.

class TrackedArray extends Array {
  static get [Symbol.species]() {
    return Array; // map/filter should return plain Arrays, not TrackedArrays
  }
}

const tracked = new TrackedArray(1, 2, 3);
const mapped = tracked.map((x) => x * 2);

console.log(mapped instanceof TrackedArray); // false
console.log(mapped instanceof Array);        // true

This is useful when our subclass has expensive setup (like tracking or validation) that we don’t want to trigger for every intermediate array operation.

When Abstraction Helps vs When It Hurts

Abstraction is powerful, but overdoing it is a real problem. Here’s a simple rule:

• Good abstraction — hides complexity that callers genuinely don’t need to know about
• Bad abstraction — adds layers of indirection that make debugging harder without real benefit

If we have only one implementation of an “interface” and we’ll probably never have another — just use the concrete thing directly. We don’t need a DatabaseInterface base class if we’re only ever going to use PostgreSQL. We can always add the abstraction later when a second implementation actually shows up.

In simple language, abstraction in JavaScript is about exposing a simple surface while keeping the complex wiring hidden. We don’t have abstract classes like Java, but throwing errors in base methods and using factory functions gets us most of the way there — without overcomplicating things.

this is one of the most confusing parts of JavaScript, and it comes up in almost every OOP interview. The key thing to understand: this is NOT fixed when we write the code — it’s determined when the function is called. The same function can have different this values depending on how we call it.

The Rules of this

There are a few simple rules. Once we know them, this stops being mysterious.

this in Global Context

In the global scope (outside any function), this refers to the global object — window in browsers, globalThis everywhere.

console.log(this === window); // true (in a browser)

this in Regular Functions

For a regular function, this depends on how it’s called, not where it’s written.

function showThis() {
  console.log(this);
}

showThis();          // window (sloppy mode) or undefined (strict mode)

const obj = { name: "Manish", showThis };
obj.showThis();      // { name: "Manish", showThis: f } — the object before the dot

The same function, two different this values. That’s the core idea.

this in Object Methods

When we call a method on an object, this is the object that owns the method — the thing before the dot.

const user = {
  name: "Manish",
  greet() {
    console.log(`Hi, I'm ${this.name}`);
  }
};

user.greet(); // Hi, I'm Manish — this = user

this in Constructors

When we use new, JavaScript creates a fresh empty object and sets this to point to it.

function Person(name) {
  this.name = name; // this = the new object being created
}

const p = new Person("Manish");
console.log(p.name); // "Manish"

Arrow Functions & Lexical this

Arrow functions don’t get their own this. They capture this from wherever they were defined. This is called lexical this and it’s one of the biggest reasons arrow functions exist.

const team = {
  name: "Avengers",
  members: ["Tony", "Steve"],
  printMembers() {
    this.members.forEach((member) => {
      console.log(`${member} is in ${this.name}`); // this = team (from printMembers)
    });
  }
};

team.printMembers(); // Tony is in Avengers, Steve is in Avengers

If we used a regular function inside forEach, this would be undefined (strict mode) instead of team. Arrow functions save us here.

call(), apply(), and bind()

These let us explicitly set this:

• call(thisArg, arg1, arg2, ...) — calls the function immediately with the given this
• apply(thisArg, [argsArray]) — same as call, but arguments are an array
• bind(thisArg) — returns a new function with this permanently set

function greet(greeting) {
  console.log(`${greeting}, I'm ${this.name}`);
}

const user = { name: "Manish" };

greet.call(user, "Hey");     // Hey, I'm Manish
greet.apply(user, ["Hey"]);  // Hey, I'm Manish

const boundGreet = greet.bind(user);
boundGreet("Hey");           // Hey, I'm Manish

The only difference between call and apply is how we pass arguments — individually vs as an array.

this in Event Handlers

In DOM event handlers, this is the element that the listener is attached to.

button.addEventListener("click", function () {
  console.log(this); // the button element
  this.style.color = "red";
});

// But with arrow function:
button.addEventListener("click", () => {
  console.log(this); // NOT the button — it's the outer this (probably window)
});

This is one case where we actually want a regular function, not an arrow function.

The Classic Pitfall: Losing this

The most common bug with this happens when we pass a method as a callback. The method gets detached from its object and this becomes undefined.

class Timer {
  constructor() {
    this.seconds = 0;
  }
  start() {
    // BUG: regular function loses this
    // setInterval(function() { this.seconds++; }, 1000); // this = undefined!

    // FIX 1: arrow function (inherits this from start())
    setInterval(() => { this.seconds++; }, 1000);

    // FIX 2: bind
    // setInterval(function() { this.seconds++; }.bind(this), 1000);
  }
}

Whenever we see this inside a callback and it’s not working, the first thing to check is whether we’re using an arrow function or need to .bind(this).

this in Classes

Class methods behave like object methods — this is the instance. But the same “losing this” problem applies if we pass a method as a callback.

class Logger {
  prefix = "[LOG]";
  log(msg) {
    console.log(`${this.prefix} ${msg}`);
  }
}

const logger = new Logger();
logger.log("hello");           // [LOG] hello

const fn = logger.log;
// fn("hello");                // TypeError: Cannot read properties of undefined

const boundFn = logger.log.bind(logger);
boundFn("hello");              // [LOG] hello

In simple language, this in JavaScript isn’t about where we write the function — it’s about how we call it. Arrow functions are the exception because they lock in this from their surrounding scope. When in doubt, check the call site or use .bind().

Sometimes we need more control over what happens when a property is read or written. Maybe we want to validate data before it’s stored, compute a value on the fly, or log every property access. JavaScript gives us three tools for this: getters/setters, Object.defineProperty, and Proxy.

Getters and Setters in Object Literals

A getter runs when we read a property. A setter runs when we assign to it. They look like regular properties from the outside, but they’re actually function calls under the hood.

const user = {
  firstName: "Manish",
  lastName: "Prajapati",
  get fullName() {
    return `${this.firstName} ${this.lastName}`; // computed on access
  },
  set fullName(value) {
    const [first, last] = value.split(" ");
    this.firstName = first;
    this.lastName = last;
  }
};

console.log(user.fullName);       // "Manish Prajapati" (calls getter)
user.fullName = "Tony Stark";     // calls setter
console.log(user.firstName);      // "Tony"

We access fullName like a normal property — no parentheses needed. That’s the whole point: it feels like data, but it’s actually logic.

Getters and Setters in Classes

Same idea, but inside a class:

class Temperature {
  #celsius; // private field

  constructor(celsius) {
    this.#celsius = celsius;
  }
  get fahrenheit() {
    return this.#celsius * 9 / 5 + 32;
  }
  set fahrenheit(f) {
    this.#celsius = (f - 32) * 5 / 9;
  }
}

const temp = new Temperature(100);
console.log(temp.fahrenheit);  // 212 (computed from celsius)
temp.fahrenheit = 32;          // sets celsius to 0

This is great for validation too — we can check values in the setter and throw if they’re invalid.

Object.defineProperty

For more control, Object.defineProperty lets us add getters/setters to existing objects and configure whether properties are enumerable, writable, etc.

const account = { _balance: 0 };

Object.defineProperty(account, "balance", {
  get() { return this._balance; },
  set(value) {
    if (value < 0) throw new Error("Balance can't be negative");
    this._balance = value;
  },
  enumerable: true
});

account.balance = 100;  // works
// account.balance = -50; // Error: Balance can't be negative

This is lower-level than class syntax, but useful when we need to add accessors dynamically or configure property descriptors.

Enter the Proxy

Proxy is a whole different level. It wraps an entire object and intercepts any operation on it — not just specific properties. Think of it as a security guard that sits between the outside world and our object.

const user = { name: "Manish", age: 25 };

const proxy = new Proxy(user, {
  get(target, prop) {
    console.log(`Reading ${prop}`);
    return target[prop];
  },
  set(target, prop, value) {
    console.log(`Setting ${prop} to ${value}`);
    target[prop] = value;
    return true; // must return true for success
  }
});

proxy.name;           // logs: Reading name → "Manish"
proxy.age = 26;       // logs: Setting age to 26

A Proxy takes two arguments: the target (the original object) and a handler (an object with “trap” functions that intercept operations).

Common Proxy Traps

Here are the traps we’ll use most often:

const schema = {
  name: "string",
  age: "number"
};

const validated = new Proxy({}, {
  set(target, prop, value) {
    if (schema[prop] && typeof value !== schema[prop]) {
      throw new TypeError(`${prop} must be a ${schema[prop]}`);
    }
    target[prop] = value;
    return true;
  }
});

validated.name = "Manish"; // works
validated.age = 25;        // works
// validated.age = "old";  // TypeError: age must be a number

The Reflect API

Reflect provides default behavior for all the proxy traps. Instead of doing target[prop] ourselves, we use Reflect.get(target, prop). This matters because Reflect methods handle edge cases (like getters with the right this) that manual access can miss.

const logged = new Proxy({}, {
  get(target, prop, receiver) {
    console.log(`Accessed: ${String(prop)}`);
    return Reflect.get(target, prop, receiver); // proper default behavior
  },
  set(target, prop, value, receiver) {
    console.log(`Set: ${String(prop)} = ${value}`);
    return Reflect.set(target, prop, value, receiver);
  }
});

The rule of thumb: inside proxy traps, use Reflect methods instead of direct object operations.

Practical Use Cases

Reactive objects — This is how Vue 3’s reactivity works. A Proxy detects when data changes and triggers re-renders.

Auto-populating defaults:

const withDefaults = new Proxy({}, {
  get(target, prop) {
    if (!(prop in target)) {
      target[prop] = []; // auto-create empty array for missing keys
    }
    return target[prop];
  }
});

withDefaults.users.push("Manish"); // no need to initialize users first
console.log(withDefaults.users);   // ["Manish"]

Negative array indexing:

const arr = new Proxy([10, 20, 30], {
  get(target, prop) {
    const index = Number(prop);
    if (index < 0) return target[target.length + index]; // arr[-1] = last element
    return Reflect.get(target, prop);
  }
});

console.log(arr[-1]); // 30
console.log(arr[-2]); // 20

Proxy vs Getters/Setters

Use getters/setters when we know exactly which properties need special behavior. Use Proxy when we need to intercept everything dynamically.

In simple language, getters and setters let us run code when a specific property is read or written — great for validation and computed values. Proxy goes further and intercepts every operation on an entire object, which is what powers frameworks like Vue 3 under the hood.

We’ve all heard the advice: “favor composition over inheritance.” But what does that actually mean? And why do experienced developers keep saying it? Let’s break it down.

The Problem with Deep Inheritance

Inheritance creates a tight parent-child coupling. Change something in the parent and every child feels it. This is called the fragile base class problem.

class Animal {
  constructor(name) { this.name = name; }
  move() { console.log(`${this.name} moves`); }
}

class Bird extends Animal {
  fly() { console.log(`${this.name} flies`); }
}

class Penguin extends Bird {
  // Penguins can't fly! But they inherit fly() from Bird.
  // Now we have to override it to throw or do nothing. Awkward.
  fly() { throw new Error("Penguins can't fly!"); }
}

The hierarchy says “a Penguin IS a Bird” and “a Bird CAN fly.” But that’s not true for all birds. This is where inheritance breaks down — real-world things don’t fit neatly into tree structures.

Mixins with Object.assign

A mixin is simply an object whose methods we copy onto another object or class. Think of it like adding abilities to a character in a game — pick and choose what fits.

const canFly = {
  fly() { console.log(`${this.name} is flying`); }
};

const canSwim = {
  swim() { console.log(`${this.name} is swimming`); }
};

class Duck {
  constructor(name) { this.name = name; }
}

Object.assign(Duck.prototype, canFly, canSwim); // mix in both abilities

const duck = new Duck("Donald");
duck.fly();  // Donald is flying
duck.swim(); // Donald is swimming

Object.assign copies the methods from the mixin objects onto the class prototype. Every Duck instance now has fly() and swim().

Functional Mixins

A more powerful approach is to use functions that take a class and return a new class with extra behavior. This lets the mixin have its own state and constructor logic.

const Serializable = (Base) => class extends Base {
  serialize() {
    return JSON.stringify(this);
  }
  static deserialize(json) {
    return Object.assign(new this(), JSON.parse(json));
  }
};

const Timestamped = (Base) => class extends Base {
  constructor(...args) {
    super(...args);
    this.createdAt = new Date();
  }
};

class User {
  constructor(name) { this.name = name; }
}

class TrackedUser extends Timestamped(Serializable(User)) {}

const user = new TrackedUser("Manish");
console.log(user.serialize());  // {"name":"Manish","createdAt":"..."}
console.log(user.createdAt);    // Date object

We stack the mixins by nesting them. Each one adds a layer. The order matters — Timestamped runs its constructor after Serializable, which runs after User.

The Diamond Problem

In languages with multiple inheritance (like C++), we can get the diamond problem: class D inherits from B and C, both of which inherit from A. Which version of A’s methods does D get? JavaScript avoids this entirely because it only has single inheritance with extends. Mixins are just method copying, not real inheritance chains — so there’s no diamond.

If two mixins define the same method name, the last one wins (since Object.assign overwrites).

Delegation Pattern

Delegation means forwarding method calls to another object instead of inheriting from it. The delegating object says “I don’t know how to do this — but I know someone who does.”

class Engine {
  start() { console.log("Engine started"); }
  stop() { console.log("Engine stopped"); }
}

class Car {
  constructor() {
    this.engine = new Engine(); // Car HAS an engine (not IS an engine)
  }
  start() { this.engine.start(); } // delegate to engine
  stop() { this.engine.stop(); }
}

const car = new Car();
car.start(); // Engine started

The car doesn’t inherit from the engine. It owns an engine and delegates work to it. This is composition — building objects from parts rather than building class hierarchies.

Composition with Closures

We can compose behavior using plain functions and closures, no classes needed:

function createPlayer(name) {
  const state = { name, hp: 100 };

  return {
    getName: () => state.name,
    getHP: () => state.hp,
    takeDamage: (dmg) => { state.hp = Math.max(0, state.hp - dmg); },
    heal: (amount) => { state.hp = Math.min(100, state.hp + amount); }
  };
}

const player = createPlayer("Manish");
player.takeDamage(30);
console.log(player.getHP()); // 70

No this, no prototype, no class — just functions and data. The state is completely private thanks to the closure.

Real-World Example: Event Emitter Mixin

Here’s a practical mixin that adds event emitter behavior to any class:

const EventEmitter = (Base) => class extends Base {
  #listeners = {};

  on(event, fn) {
    (this.#listeners[event] ??= []).push(fn);
  }
  off(event, fn) {
    this.#listeners[event] = (this.#listeners[event] || []).filter(cb => cb !== fn);
  }
  emit(event, ...args) {
    (this.#listeners[event] || []).forEach(fn => fn(...args));
  }
};

class Store extends EventEmitter(class {}) {
  #data = {};
  set(key, value) {
    this.#data[key] = value;
    this.emit("change", { key, value });
  }
}

const store = new Store();
store.on("change", (e) => console.log(`${e.key} changed to ${e.value}`));
store.set("theme", "dark"); // "theme changed to dark"

Any class can gain event emitter powers by mixing in EventEmitter. No inheritance hierarchy needed.

In simple language, inheritance says “this thing IS a type of that thing” while composition says “this thing HAS these abilities.” Composition is more flexible because we can mix and match behaviors without getting locked into a rigid class tree. Use inheritance for true “is-a” relationships and composition for everything else.

Symbols are a primitive type added in ES6. Each Symbol is guaranteed to be unique — even if two Symbols have the same description. But the real OOP power comes from well-known Symbols — special built-in Symbols that let us hook into JavaScript’s internal behavior.

What Is a Symbol?

A Symbol is a unique, immutable identifier. Unlike strings, two Symbols are never equal.

const a = Symbol("id");
const b = Symbol("id");
console.log(a === b); // false — each Symbol is unique

// We use Symbols as property keys
const user = { [a]: 123 };
console.log(user[a]); // 123

Symbols don’t show up in for...in loops or Object.keys(), making them perfect for “hidden” metadata on objects.

Why Well-Known Symbols Matter for OOP

JavaScript has a set of built-in Symbols (like Symbol.iterator, Symbol.toPrimitive) that act as hooks. When we define methods with these Symbol keys on our objects, we’re telling JavaScript how our object should behave with built-in operations like for...of, string conversion, and instanceof.

In simple language, well-known Symbols let our custom objects “speak JavaScript’s language.”

Symbol.iterator — Making Objects Iterable

When we use for...of on an array, JavaScript calls array[Symbol.iterator]() behind the scenes. We can define this on our own objects to make them work with for...of, spread syntax, and destructuring.

An iterator is an object with a next() method that returns { value, done }.

class Range {
  constructor(start, end) {
    this.start = start;
    this.end = end;
  }
  [Symbol.iterator]() {
    let current = this.start;
    const end = this.end;
    return {
      next() {
        return current <= end
          ? { value: current++, done: false }
          : { done: true };
      }
    };
  }
}

const range = new Range(1, 5);
console.log([...range]);       // [1, 2, 3, 4, 5]
for (const n of range) { }     // works!
const [a, b] = new Range(10, 20); // a = 10, b = 11

Generators as a Shortcut

Writing iterators manually is verbose. Generators make it much cleaner. A generator function (with function*) automatically returns an iterator.

class Fibonacci {
  [Symbol.iterator]() {
    return this.generate();
  }
  *generate() {
    let [a, b] = [0, 1];
    while (true) {
      yield a;       // pauses here, returns value
      [a, b] = [b, a + b];
    }
  }
}

const first10 = [...new Fibonacci()].slice(0, 10); // won't work — infinite!

// Instead, take manually:
const fib = new Fibonacci();
const iter = fib[Symbol.iterator]();
for (let i = 0; i < 10; i++) {
  console.log(iter.next().value); // 0, 1, 1, 2, 3, 5, 8, 13, 21, 34
}

We can also use *[Symbol.iterator]() directly in a class to combine both in one:

class EvenNumbers {
  constructor(limit) { this.limit = limit; }
  *[Symbol.iterator]() {
    for (let i = 0; i <= this.limit; i += 2) yield i;
  }
}

console.log([...new EvenNumbers(10)]); // [0, 2, 4, 6, 8, 10]

Symbol.toPrimitive — Controlling Type Conversion

When JavaScript needs to convert our object to a primitive (number, string, or default), it calls [Symbol.toPrimitive](hint). The hint tells us what type is expected.

class Money {
  constructor(amount, currency) {
    this.amount = amount;
    this.currency = currency;
  }
  [Symbol.toPrimitive](hint) {
    if (hint === "number") return this.amount;
    if (hint === "string") return `${this.amount} ${this.currency}`;
    return this.amount; // default
  }
}

const price = new Money(42, "USD");
console.log(`Price: ${price}`);  // "Price: 42 USD" (hint = string)
console.log(+price);             // 42 (hint = number)
console.log(price + 10);         // 52 (hint = default)

Without this, JavaScript would just give us "[object Object]" for string conversion. Now our object converts meaningfully.

Symbol.hasInstance — Customizing instanceof

instanceof calls [Symbol.hasInstance] on the right-hand side. We can override it to change what instanceof means for our class.

class EvenNumber {
  static [Symbol.hasInstance](num) {
    return typeof num === "number" && num % 2 === 0;
  }
}

console.log(4 instanceof EvenNumber);   // true
console.log(7 instanceof EvenNumber);   // false
console.log("hi" instanceof EvenNumber); // false

This is unusual — most of the time we don’t need to override instanceof. But it’s good to know it’s possible.

Symbol.species — Controlling Derived Constructors

When we extend Array or Promise, methods like .map() and .then() need to create new instances. Symbol.species tells them which constructor to use.

class FilteredArray extends Array {
  static get [Symbol.species]() {
    return Array; // .map() returns a plain Array, not FilteredArray
  }
}

const filtered = new FilteredArray(1, 2, 3);
const doubled = filtered.map(x => x * 2);

console.log(doubled instanceof FilteredArray); // false
console.log(doubled instanceof Array);         // true

This is handy when our subclass has expensive constructors or special initialization that shouldn’t run for every intermediate operation.

Symbol.toStringTag

When we call Object.prototype.toString.call(something), it returns "[object Type]". We can control Type with Symbol.toStringTag.

class Database {
  get [Symbol.toStringTag]() {
    return "Database";
  }
}

const db = new Database();
console.log(Object.prototype.toString.call(db)); // [object Database]

This is useful for debugging — we can give our custom classes meaningful type tags instead of the generic "[object Object]".

Quick Reference

In simple language, well-known Symbols are hooks that let our custom objects plug into JavaScript’s built-in operations. The most practically useful one is Symbol.iterator — it lets any object work with for...of and spread syntax, which comes up all the time.

SOLID is a set of five design principles that help us write code that’s easier to maintain, extend, and test. They were originally coined for OOP in languages like Java, but they apply just as well to JavaScript — we just use idiomatic JS patterns like callbacks, modules, and mixins instead of formal interfaces.

Let’s go through each one with a bad example, then the fixed version.

S — Single Responsibility Principle

One class (or module) should have only one reason to change.

If a class does too many things, changing one part risks breaking the others.

Bad — one class does everything:

class UserService {
  createUser(data) { /* save to DB */ }
  sendWelcomeEmail(user) { /* send email */ }
  generateReport(user) { /* create PDF */ }
}

This class has three reasons to change: DB logic, email logic, and report logic.

Good — split by responsibility:

class UserRepository {
  create(data) { /* save to DB */ }
}

class EmailService {
  sendWelcome(user) { /* send email */ }
}

class ReportGenerator {
  generate(user) { /* create PDF */ }
}

Now each class has one job. If the email provider changes, only EmailService changes.

O — Open/Closed Principle

Open for extension, closed for modification.

We should be able to add new behavior without modifying existing code. In JS, we do this with strategy patterns, plugins, or callbacks.

Bad — modifying existing code for every new shape:

class AreaCalculator {
  calculate(shape) {
    if (shape.type === "circle") return Math.PI * shape.radius ** 2;
    if (shape.type === "rectangle") return shape.width * shape.height;
    // Every new shape = modify this function
  }
}

Good — each shape knows how to calculate its own area:

class Circle {
  constructor(radius) { this.radius = radius; }
  area() { return Math.PI * this.radius ** 2; }
}

class Rectangle {
  constructor(w, h) { this.width = w; this.height = h; }
  area() { return this.width * this.height; }
}

// Adding a Triangle doesn't touch Circle or Rectangle
function totalArea(shapes) {
  return shapes.reduce((sum, s) => sum + s.area(), 0);
}

New shapes just implement area(). The totalArea function never changes.

L — Liskov Substitution Principle

Subclasses must be substitutable for their parent class without breaking anything.

If we have code that works with a parent class, swapping in a child class should not cause surprises.

Bad — the subclass breaks the parent’s contract:

class Bird {
  fly() { return "flying"; }
}

class Penguin extends Bird {
  fly() { throw new Error("Can't fly!"); } // breaks the contract!
}

function makeBirdFly(bird) {
  return bird.fly(); // crashes if we pass a Penguin
}

Good — restructure so the contract holds:

class Bird {
  move() { return "moving"; }
}

class FlyingBird extends Bird {
  fly() { return "flying"; }
}

class Penguin extends Bird {
  swim() { return "swimming"; }
}

// Now we only call fly() on FlyingBird, not all Birds

The rule is simple: if a subclass can’t do everything the parent promises, it shouldn’t extend that parent.

I — Interface Segregation Principle

Don’t force classes to implement methods they don’t need.

JavaScript doesn’t have formal interfaces, but the idea still applies. Instead of one giant mixin or base class with everything, we use small focused mixins.

Bad — one fat interface:

class Animal {
  fly() { throw new Error("Not implemented"); }
  swim() { throw new Error("Not implemented"); }
  walk() { throw new Error("Not implemented"); }
}

class Dog extends Animal {
  walk() { return "walking"; }
  // Forced to inherit fly() and swim() which make no sense
}

Good — small, role-based mixins:

const Walkable = (Base) => class extends Base {
  walk() { return `${this.name} is walking`; }
};

const Swimmable = (Base) => class extends Base {
  swim() { return `${this.name} is swimming`; }
};

class Dog extends Walkable(Swimmable(class {
  constructor(name) { this.name = name; }
})) {}

const dog = new Dog("Buddy");
dog.walk(); // "Buddy is walking"
dog.swim(); // "Buddy is swimming"
// No fly() — Dog doesn't need it

Each mixin adds only what’s relevant. Classes pick only the abilities they need.

D — Dependency Inversion Principle

Depend on abstractions, not concretions.

High-level modules shouldn’t depend directly on low-level modules. Both should depend on abstractions (callbacks, interfaces, injection).

Bad — tightly coupled to a specific database:

class UserService {
  constructor() {
    this.db = new PostgresDB(); // hardcoded dependency
  }
  getUser(id) {
    return this.db.query(`SELECT * FROM users WHERE id = ${id}`);
  }
}

If we want to switch to MongoDB or use a mock in tests, we have to change UserService.

Good — inject the dependency:

class UserService {
  constructor(db) {
    this.db = db; // accepts any object with a query() method
  }
  getUser(id) {
    return this.db.findById("users", id);
  }
}

// Production
const service = new UserService(new PostgresDB());

// Tests
const service = new UserService(new MockDB());

Now UserService doesn’t care what database it’s using. It just needs something with a findById() method. In JS, we don’t need a formal interface — we rely on duck typing (“if it has the right methods, it works”).

SOLID at a Glance

In simple language, SOLID principles are guidelines, not strict rules. We don’t need to apply all five everywhere — that’s overengineering. But knowing them helps us recognize when a class is doing too much, when inheritance is the wrong tool, or when our code is too tightly coupled. Use them as a compass, not a rulebook.

Design patterns are proven solutions to problems that keep showing up in software. We don’t need to memorize all 23 GoF patterns, but knowing the most common ones helps us write cleaner code and recognize them in frameworks we already use. Let’s look at seven patterns that come up most in JavaScript.

Singleton — One Instance, Ever

A Singleton ensures only one instance of a class exists. Useful for things like a config manager, logger, or database connection pool.

In modern JS, the simplest Singleton is just a module-level instance — since ES modules are cached, the same instance is returned every time.

// logger.js
class Logger {
  #logs = [];
  log(msg) {
    this.#logs.push({ msg, time: Date.now() });
    console.log(`[LOG] ${msg}`);
  }
  getHistory() { return [...this.#logs]; }
}

export const logger = new Logger(); // single instance, module-cached

Anyone who imports logger gets the exact same object. No need for getInstance() gymnastics — the module system handles it.

If we need a class-based approach (for interviews):

class AppConfig {
  static #instance;
  #settings = {};

  static getInstance() {
    if (!AppConfig.#instance) AppConfig.#instance = new AppConfig();
    return AppConfig.#instance;
  }
  set(key, val) { this.#settings[key] = val; }
  get(key) { return this.#settings[key]; }
}

const a = AppConfig.getInstance();
const b = AppConfig.getInstance();
console.log(a === b); // true

Factory — Create Without Specifying the Exact Class

A Factory function creates objects without the caller knowing the exact class or construction details. The caller says what they want, and the factory figures out how to build it.

class PostgresDB {
  query(sql) { console.log(`Postgres: ${sql}`); }
}
class MongoDB {
  query(sql) { console.log(`Mongo: ${sql}`); }
}

function createDatabase(type) {
  if (type === "postgres") return new PostgresDB();
  if (type === "mongo") return new MongoDB();
  throw new Error(`Unknown database: ${type}`);
}

const db = createDatabase("postgres");
db.query("SELECT * FROM users"); // Postgres: SELECT * FROM users

The caller doesn’t import or know about PostgresDB or MongoDB directly. If we add MySQL later, only the factory changes. React.createElement() is a real-world factory.

Builder — Step-by-Step Construction

The Builder pattern builds complex objects step by step, usually with a fluent API (method chaining). Great when an object has many optional configurations.

class QueryBuilder {
  #table = "";
  #conditions = [];
  #limit = null;

  from(table) { this.#table = table; return this; }
  where(condition) { this.#conditions.push(condition); return this; }
  limit(n) { this.#limit = n; return this; }
  build() {
    let sql = `SELECT * FROM ${this.#table}`;
    if (this.#conditions.length) sql += ` WHERE ${this.#conditions.join(" AND ")}`;
    if (this.#limit) sql += ` LIMIT ${this.#limit}`;
    return sql;
  }
}

const query = new QueryBuilder()
  .from("users")
  .where("age > 18")
  .where("active = true")
  .limit(10)
  .build();
// "SELECT * FROM users WHERE age > 18 AND active = true LIMIT 10"

Each method returns this so we can chain calls. The build() at the end produces the final result. Express middleware and Knex.js query builder use this pattern.

Observer — Subscribe to Changes

The Observer (or Pub/Sub) pattern lets objects subscribe to events and get notified when something happens. One object emits events, many objects listen.

class EventBus {
  #listeners = new Map();

  on(event, callback) {
    if (!this.#listeners.has(event)) this.#listeners.set(event, []);
    this.#listeners.get(event).push(callback);
  }
  off(event, callback) {
    const cbs = this.#listeners.get(event) || [];
    this.#listeners.set(event, cbs.filter(cb => cb !== callback));
  }
  emit(event, data) {
    (this.#listeners.get(event) || []).forEach(cb => cb(data));
  }
}

const bus = new EventBus();
bus.on("user:login", (user) => console.log(`${user} logged in`));
bus.emit("user:login", "Manish"); // "Manish logged in"

This is everywhere: addEventListener in the DOM, Node’s EventEmitter, Redux subscriptions, and Vue/React state management all use Observer under the hood.

Strategy — Swap Algorithms at Runtime

The Strategy pattern lets us define a family of algorithms and swap them out without changing the code that uses them. In JS, we just pass functions around — first-class functions make this natural.

// Define strategies as simple functions
const strategies = {
  standard: (amount) => amount * 0.1,     // 10% tax
  reduced: (amount) => amount * 0.05,     // 5% tax
  exempt: () => 0                          // no tax
};

function calculateTax(amount, type = "standard") {
  const strategy = strategies[type];
  if (!strategy) throw new Error(`Unknown tax type: ${type}`);
  return strategy(amount);
}

console.log(calculateTax(100, "standard")); // 10
console.log(calculateTax(100, "reduced"));  // 5
console.log(calculateTax(100, "exempt"));   // 0

Adding a new tax type is just adding a new key to the strategies object. No if/else chains, no modifying existing code. This also ties directly to the Open/Closed principle from SOLID.

Decorator — Wrap to Add Behavior

The Decorator pattern wraps an object to add extra behavior without modifying the original. In JS, higher-order functions are the natural way to do this.

function withLogging(fn) {
  return function (...args) {
    console.log(`Calling ${fn.name} with`, args);
    const result = fn(...args);
    console.log(`Result:`, result);
    return result;
  };
}

function add(a, b) { return a + b; }

const loggedAdd = withLogging(add);
loggedAdd(2, 3);
// Calling add with [2, 3]
// Result: 5

We can also decorate class instances:

function withTimestamp(instance) {
  const original = instance.save.bind(instance);
  instance.save = function (data) {
    return original({ ...data, updatedAt: new Date() });
  };
  return instance;
}

Express middleware is essentially a decorator chain — each middleware wraps the request/response to add behavior (logging, auth, CORS) before passing it along.

Proxy Pattern — Control Access

The Proxy pattern controls access to an object. JavaScript has this built into the language with the Proxy API, but the pattern itself is about adding a layer between the caller and the real object.

function createCachedAPI(apiClient) {
  const cache = new Map();

  return new Proxy(apiClient, {
    get(target, prop) {
      if (prop === "fetch") {
        return async (url) => {
          if (cache.has(url)) {
            console.log("Cache hit");
            return cache.get(url);
          }
          const result = await target.fetch(url);
          cache.set(url, result);
          return result;
        };
      }
      return Reflect.get(target, prop);
    }
  });
}

The proxy sits between the caller and the API client, transparently adding caching. The caller doesn’t know (or care) that caching is happening.

Quick Reference

In simple language, design patterns aren’t rules we have to follow — they’re names for solutions we’ve probably already used without knowing it. Recognizing them helps us communicate with other developers and pick the right tool when we face a familiar problem.

A class is a blueprint for creating objects. Think of it like a cookie cutter — the class defines the shape, and every cookie we stamp out is an instance (an actual object in memory).

The class Keyword

We define a class with the class keyword. By convention, class names use PascalCase.

class Dog:
    species = "Canis familiaris"  # class attribute — shared by ALL dogs

    def __init__(self, name, age):
        self.name = name  # instance attribute — unique to each dog
        self.age = age

What Is __init__?

__init__ is the initializer, not the constructor. The actual constructor is __new__ (which creates the object). __init__ just sets up the initial state after the object already exists.

In simple language, __init__ is where we say “okay, this new object should have these attributes with these values.”