Classes & OOP in JavaScript

When data and behaviour belong together — a Task that knows how to complete itself, a Cart that computes its total — classes give you a clean blueprint. JavaScript's class syntax (ES6) runs on a prototype-based engine underneath; this chapter teaches the modern syntax, inheritance, encapsulation, and when not to use classes.

The class blueprint

class Task {
  title = 'Untitled';              // field (public)

  constructor(title, done = false) {
    this.title = title;            // 'this' = the new instance
    this.done = done;
  }

  complete() {                     // method (shared on the prototype)
    this.done = true;
    return `${this.title} ✓`;
  }

  toString() {
    return `${this.title}${this.done ? ' ✓' : ''}`;
  }
}

const t = new Task('Ship release');
console.log(t.complete());   // → Ship release ✓
console.log(String(t));      // → Ship release ✓ (calls toString)

new creates the object, runs constructor, returns the instance. Methods live on the prototype — every instance shares one copy.

Getters and setters

class Temperature {
  #celsius = 0;                      // private field (see below)

  constructor(c) { this.#celsius = c; }

  get fahrenheit() {
    return this.#celsius * 9 / 5 + 32;
  }

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

const room = new Temperature(20);
console.log(room.fahrenheit);   // → 68 (property access, not a method call)
room.fahrenheit = 100;
console.log(room.fahrenheit);   // → 212 (setter updated the private field)

Getters/setters let you validate or compute on access while consumers use plain property syntax.

Private fields: real encapsulation

class BankAccount {
  #balance = 0;                     // hard privacy — even 'this' outside cannot touch it

  deposit(amount) {
    if (amount <= 0) throw new RangeError('Amount must be positive');
    this.#balance += amount;
    return this.#balance;
  }

  get balance() { return this.#balance; }
}

const acc = new BankAccount();
acc.deposit(100);
console.log(acc.balance);      // → 100
acc.#balance;                  // ❌ SyntaxError: Private field

Expected output: the balance can change only through validated methods — encapsulation, the first pillar of OOP, enforced by the language. (The older _underscore convention is only a gentleman's agreement; # is real.)

Static members

class Utils {
  static clamp(n, min, max) { return Math.min(max, Math.max(min, n)); }
  static VERSION = '1.2.0';
}

console.log(Utils.clamp(15, 0, 10));   // → 10 (no instance needed)

Static methods belong to the class itself — factories (User.create()), helpers, constants. They do not have instance this.

Inheritance: extends and super

class Animal {
  #name;
  constructor(name) { this.#name = name; }
  speak() { return `${this.#name} makes a sound`; }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name);                    // MUST run before using 'this'
    this.breed = breed;
  }

  speak() {                        // overriding
    return `${this.constructor.name} barks`;
  }
}

const d = new Dog('Rex', 'Beagle');
console.log(d.speak());             // → Dog barks
console.log(d instanceof Dog);      // → true
console.log(d instanceof Animal);   // → true

• extends sets the prototype chain; super() calls the parent constructor (required before this).
• Override a method simply by redefining it; call the parent version with super.method().
• instanceof walks the whole chain.

Composition over inheritance

// inheritance: "is-a" — fine when the relationship is true
class Admin extends User { … }

// composition: "has-a" — usually more flexible
class Task {
  constructor(title, assignee = null) {
    this.title = title;
    this.assignee = assignee;        // a User object, not extends User
  }
}

Favor small classes collaborating via composition; deep inheritance trees are hard to change. Inheritance fits clear is-a hierarchies (two or three levels deep at most).

Where classes shine (and where they don't)

A brief word on prototypes

function LegacyPoint(x, y) { this.x = x; this.y = y; }   // pre-ES6 style
LegacyPoint.prototype.dist = function () { return Math.hypot(this.x, this.y); };

const p = new LegacyPoint(3, 4);
console.log(p.dist());   // → 5

Classes are sugar over exactly this: the constructor function, Prototype.prototype, and [[Prototype]] chains (which also power extends). You do not need the old syntax, but understanding prototypes explains how methods are shared and why this works.

Common mistakes

• Forgetting new — calling a class without it throws TypeError (unlike old constructor functions).
• Using this before super() — ReferenceError.
• Arrow functions as class methods — they are not prototype methods (class A { fn = () => {} } creates a per-instance field — sometimes intentional for callbacks, but different semantics).
• Everything-is-a-class — over-engineering simple data; use the table above.
• Forgetting that methods are shared — never mutate a method on one instance expecting others to change.
• Public mutable state — add validation via methods/getters instead of letting outside code do obj.x = anything.

Practice checklist

1. Model a TodoList class: private array, add/remove/count methods, getters.
2. Create ValidationError extends Error and catch it by name (used later in real projects constantly).
3. Build a small Game with Player extends Entity, overriding act().
4. Refactor a “god function” into 2–3 collaborating classes/functions and compare readability.

Your architecture is taking shape — but where does data survive a page reload? Next: Browser Storage & Web APIs.