OOP principles in JavaScript

What OOP means in JavaScript

Object-oriented programming, or OOP, is a way to organize code around objects. An object holds some data, and the methods (functions) that work on that data. You don't have to use OOP to write JavaScript. You can also build good programs with plain functions, modules, closures, and plain objects. Most real programs mix all of these.

The useful core of OOP is small. An object offers a short list of methods that other code may call. That list is the object's public interface. Other code uses only that list. Everything else stays hidden inside the object.

Here are two objects from this lesson:

• A Thermostat offers setTarget() and display.
• A Circle, a Square, and a Triangle all offer area() and draw().

Code that uses these objects calls only those methods. It doesn't need the hidden parts: private fields, maths formulas, or how the object stores its data.

This lesson ends the Classes module. You have already seen:

• class syntax;
• extends and super;
• static members;
• #private fields;
• extending built-in classes;
• mixins.

Two earlier lessons help here too: Closure patterns and Delegation vs classical inheritance. They show that JavaScript doesn't have to copy the class style of languages like Java. Stage 9 goes further, with Creational patterns and Structuring an application. This lesson stays practical, with code you can run.

Encapsulation means keeping data, and the methods that look after it, together inside one object. The object protects its own rules. A rule here is something that must always be true, like "the target temperature is between 10 and 35".

JavaScript gives you several ways to hide data inside an object:

• #private fields and methods in a class. Only code inside the class body can use them.
• Variables in a closure. A closure is a function that keeps using the variables from the place where it was made.
• Variables in a module that the module doesn't export.
• A naming habit, like starting a property name with _. This only asks people not to touch it. It doesn't stop them.

Which way you choose matters less than the result: outside code gets fewer ways to break the object's rules.

Abstraction means giving other code a simple idea to use, and hiding the steps behind it. Other code should just write thermostat.setTarget(22). It should not have to check the range, store the number, and build the display text itself. The public method is the simple idea. The private field and the checks are the hidden steps.

class Wallet {
  #balance = 0;

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

const wallet = new Wallet();
console.log(wallet.add(3));
console.log(wallet.balance);

Line 2 creates a private field, #balance, inside Wallet. Only code inside the class can use it. Line 5 changes it from inside the add() method, so line 11 prints 3. Line 12 asks for wallet.balance, with no #. That is a different, public property. The wallet has no such property, so line 12 prints undefined.

function printArea(shape) {
  return "Area: " + shape.area();
}

const tile = {
  area() {
    return 12;
  },
  color: "blue",
};

console.log(printArea(tile));

printArea() uses only one method of the object it gets: area(). The tile object also has a color, but printArea() never looks at it. So line 12 prints Area: 12. Because printArea() asks for so little, any object with an area() method works with it.

Now try the thermostat below. It has one private field, #targetCelsius, which starts at 20. It has two public parts:

• setTarget(value) asks for a new temperature. It accepts only 10 to 35°C.
• display is a getter: a method you read like a property, with no brackets. It returns the temperature as text.

Pick 22, then 41 or -5, and step through. For 41 and -5, the method says no before it changes anything. The private field stays at 20, because setTarget() is the only way in, and it checks first.

1class Thermostat {2  #targetCelsius = 20;3 4  setTarget(value) {5    if (value < 10 || value > 35) {6      return "Refused " + value + "°C";7    }8 9    this.#targetCelsius = value;10    return "Target is " + this.#targetCelsius + "°C";11  }12 13  get display() {14    return this.#targetCelsius + "°C";15  }16}17 18const thermostat = new Thermostat();Run19console.log(thermostat.display);20console.log(thermostat.setTarget(22));21console.log(thermostat.display);

Polymorphism means "many forms". In JavaScript the idea is simple. Several objects can have a method with the same name. Code can call that method on any of them. Each object runs its own version.

JavaScript doesn't ask you to declare this anywhere. The code just calls the method, and the object decides what happens.

The shapes example below also shows a SOLID rule called Open/Closed. It means you can add new kinds of things without editing the code that already works:

• The loop is closed to changes. It always calls draw() and area().
• The program is open to new shapes. Add a Triangle with the same two methods, and the loop works with it as it is.

Near the end of the code, the shapes array (a list) holds the shapes. The for...of loop below it visits each shape in turn and calls the same two methods. This is simpler than a chain of checks like if (shape.name === "circle"), which you would have to edit for every new shape.

1class Circle {2  constructor(radius) {3    this.name = "circle";4    this.radius = radius;5  }6 7  area() {8    return Math.PI * this.radius ** 2;9  }10 11  draw() {12    return `● circle radius ${this.radius}`;13  }14}15 16class Square {17  constructor(size) {18    this.name = "square";19    this.size = size;20  }21 22  area() {23    return this.size * this.size;24  }25 26  draw() {27    return `■ square ${this.size}×${this.size}`;28  }29}30 31const shapes = [new Circle(3), new Square(4)];Run32 33for (const shape of shapes) {34  console.log(shape.draw() + " has area " + shape.area().toFixed(2));35}

JavaScript has more than one way to make objects. These are the two most common:

• A class is a blueprint. You make objects from it with new, like new Counter("class"). Each object made this way is an instance of the class.
• A factory is a plain function that builds an object and returns it, like createCounter("factory").

A class is a good fit when:

• you make many objects that share the same methods. The methods are stored once, on the class's prototype: a shared object where every instance looks for its methods.
• you want instanceof to work. x instanceof Counter is true when x was made by new Counter().
• you want #private fields.

A factory is a good fit when:

• you want to hide data in a closure variable, like let count = 0.
• you want to build a different object depending on the arguments.
• you want to return a plain object that is easy to combine with others.

The playground below makes one counter each way. Press the button to run both.

1function createCounter(label) {2  let count = 0;3  return {4    next() {5      count += 1;6      return label + ": " + count;7    },8  };9}10 11class Counter {12  #count = 0;13  constructor(label) {14    this.label = label;15  }16 17  next() {18    this.#count += 1;19    return this.label + ": " + this.#count;20  }21}22 23const factoryCounter = createCounter("factory");24const classCounter = new Counter("class");25console.log(factoryCounter.next());26console.log(classCounter.next());27console.log(factoryCounter instanceof Counter);28console.log(classCounter instanceof Counter);

Both counters answer next() the same way: each prints its label and 1. The difference is in the last two lines. The factory's object is not an instance of Counter, so instanceof gives false. The class's object is, so it gives true.

function formatPrice(price) {
  return "$" + price.toFixed(2);
}

console.log(formatPrice(3));

Sometimes you need neither. formatPrice() turns a number into price text, like $3.00. It keeps no data between calls and has only one job. A plain function says exactly what it does. Wrapping it in a class would add extra code and give nothing useful back.

The table compares the two tools. Read each row as a question, then see how a factory and a class each answer it.

Neither column wins. Use a class when shared methods and instanceof make the code clearer. Use a factory when you want a small function, closure variables, or an object that changes with the input. Either way, other code should see only a small public interface.

SOLID started with people who design big programs out of classes. Its ideas also help in JavaScript, if you keep them light. Treat each rule as a question you ask about your code:

• How many reasons does this piece of code have to change?
• Can I add a new kind of thing without editing the loop?
• Can I pass in a fake version of a tool when I test?

These questions help whether your objects come from classes, factories, or modules.

The table lists the five rules. Read each row as: the rule, the question it asks, and a small example.

Start with Single Responsibility. It means each piece of code should have one job. Imagine a class that does four jobs:

• it loads an invoice from the server;
• it adds up the total;
• it formats the total as money text;
• it writes HTML into the page.

That class has four reasons to change. Split it into smaller pieces: a loader, a calculator, a formatter, and a renderer (the piece that shows things on the page). Each piece can be an object, a function, or a module. Small pieces are easier to test and to replace.

1class InvoiceWidget {2  async show(id) {3    const invoice = await api.loadInvoice(id);4    const total = invoice.items.reduce((sum, item) => sum + item.price, 0);5    element.textContent = "Total: $" + total.toFixed(2);6  }7}

Line 3 loads the invoice; await waits for the server to answer. Line 4 adds up the prices. Line 5 writes the total into the page. That is three jobs, so the method has three reasons to change.

1class InvoiceFormatter {2  total(invoice) {3    return invoice.items.reduce((sum, item) => sum + item.price, 0);4  }5}6 7class InvoiceRenderer {8  constructor(element, formatter) {9    this.element = element;10    this.formatter = formatter;11  }12 13  show(invoice) {14    const total = this.formatter.total(invoice);15    this.element.textContent = "Total: $" + total.toFixed(2);16  }17}

InvoiceFormatter only adds up the total. InvoiceRenderer only writes to the page. It gets the page element and the formatter through its constructor, on lines 8 to 10, instead of making them itself. Loading the invoice can live in a third piece.

Dependency Inversion is the rule that helps testing most in front-end code. A dependency is a tool your code needs, like a place to save data. Don't build the tool into the class. Pass it in from outside instead.

In the example below, the panel doesn't use localStorage (the browser's built-in storage) directly. It gets a storage object through its constructor:

• In the real app, you pass the browser's localStorage.
• In a test, you pass a small fake that keeps the data in a Map.

The panel needs only two methods from it: setItem() and getItem(). Line 2 receives the storage, line 7 uses it, and line 22 passes in the fake.

1class PreferencePanel {2  constructor(storage) {3    this.storage = storage;4  }5 6  chooseTheme(theme) {7    this.storage.setItem("theme", theme);8    return "Saved " + this.storage.getItem("theme");9  }10}11 12const memoryStorage = new Map();13const fakeStorage = {14  setItem(key, value) {15    memoryStorage.set(key, value);16  },17  getItem(key) {18    return memoryStorage.get(key);19  },20};21 22const panel = new PreferencePanel(fakeStorage);23console.log(panel.chooseTheme("dark"));

The Liskov Substitution rule is named after Barbara Liskov, the computer scientist who described it. It says: if code works with one kind of object, it should also work with a subtype of it, with no surprises. A subtype is a class that extends another class, like Square extends Rectangle.

The classic example looks harmless. A square sounds like a special kind of rectangle. But the two behave differently when you change their size:

• A rectangle has a width and a height. You can change one without the other.
• A square has one size. Its width and height must stay equal.

So if setWidth() on a square also changes the height, code written for rectangles gets a surprise. Step through the code below. makeWide() sets the width to 10 and returns the area. It expects the height to stay the same.

1class Rectangle {2  constructor(width, height) {3    this.width = width;4    this.height = height;5  }6 7  setWidth(width) {8    this.width = width;9  }10 11  area() {12    return this.width * this.height;13  }14}15 16class Square extends Rectangle {17  constructor(size) {18    super(size, size);19  }20 21  setWidth(width) {22    this.width = width;23    this.height = width;24  }25}26 27function makeWide(shape) {28  shape.setWidth(10);29  return shape.area();30}31 32console.log(makeWide(new Rectangle(4, 5)));Run33console.log(makeWide(new Square(4)));

The rectangle gives 50 (10 × 5). The square gives 100 (10 × 10), because its height changed too. Code written for rectangles did not expect that.

The fix is not a cleverer extends. Instead, make the shared promise smaller. If the code only needs area(), both shapes can offer just that, with no inheritance at all:

• The rectangle keeps its setWidth() method.
• The square keeps its own rule: one size for every side.

Not every "a square is a rectangle" sentence should become extends in code.

1class ResizableRectangle {2  constructor(width, height) {3    this.width = width;4    this.height = height;5  }6 7  setWidth(width) {8    this.width = width;9  }10 11  area() {12    return this.width * this.height;13  }14}15 16class SquareShape {17  constructor(size) {18    this.size = size;19  }20 21  area() {22    return this.size * this.size;23  }24}25 26const shapes = [new ResizableRectangle(10, 5), new SquareShape(4)];27console.log(shapes.map((shape) => shape.area()).join(", "));

Line 26 puts both shapes in one array. Line 27 calls area() on each one and prints 50, 16. Nothing changes a size it doesn't own.

class Receipt {
  constructor(sender) {
    this.sender = sender;
  }

  send(order) {
    return this.sender.send("Receipt for " + order);
  }
}

const email = {
  send(message) {
    return "Email: " + message;
  },
};

console.log(new Receipt(email).send("Asha"));

Composition means building an object out of other objects it is given, instead of inheriting from them. Receipt does not extend an email class. It gets a sender object in its constructor and calls this.sender.send(). Here the sender is email, so the last line prints Email: Receipt for Asha.

To send a text message instead, pass a different object that has a send() method. Receipt doesn't change.

Where you will use this

These ideas show up whenever a front-end program grows past one small script. For example:

• A form field object keeps its own checks and offers isValid().
• Several payment methods all offer charge(). The checkout code doesn't need to know if the user picked a card, a gift balance, or a saved wallet.
• A table component is given a sorting function, instead of having one sort order built in.
• A test passes a fake storage, a fake clock, or a fake analytics tracker into a class that normally talks to the browser.

You will also learn to notice when OOP is too much:

• If a module holds one helper function, it doesn't need a class just to look official.
• If two objects share only a small bit of behavior, a mixin, a plain function, or delegation can be cleaner than inheritance.

For choosing between bigger patterns, Creational patterns and Structuring an application come in Stage 9. For now, pick the smallest public interface that makes change easier.

Common misconceptions

Read the explanations even when you get it right. The wrong choices are common design mistakes.

Key takeaways

• Encapsulation protects an object's data. Every change goes through public methods, which can check the rules first.
• Abstraction gives other code a simple idea to use, like setTarget(22), and hides the steps behind it.
• Polymorphism lets one method call work on different objects. That is how you add new kinds of things without editing old code (Open/Closed).
• Factories and classes both work. Choose by what you need: closure variables, shared prototype methods, this, instanceof, and clear code.
• Use SOLID as five questions when you change code: one job per piece, no growing lists of if checks, replacements that keep their promises, small interfaces, and tools passed in from outside.

Up next: Property flags & descriptors. You'll look at a single object property up close, and learn the settings that control whether it can be changed, listed, or deleted.