OOP principles in JavaScript

Objects with promises

Object-oriented programming, or OOP, is not a requirement to write JavaScript. You can build excellent programs with functions, modules, closures, plain objects, prototypes, classes, or a mix of all of them. The useful part of OOP is smaller than the drama around it: an object can make a promise about what messages it understands.

A Thermostat promises setTarget() and display. A Circle, Square, and Triangle can all promise area() and draw(). Code that depends on those promises can ignore the messy details: private fields, formulas, storage choices, and constructor arguments stay behind the object’s public surface.

This lesson is the capstone for the Classes module. You have already seen class syntax, extends and super, static members, #private fields, extending built-ins, and mixins. Earlier foundations such as Closure patterns and Delegation vs classical inheritance explain why JavaScript does not need to copy another language’s class culture. Stage 9 will go further with Creational patterns and Structuring an application; today we keep the principles practical and close to code you can run.

Encapsulation means putting data and the operations that protect it together. The object owns its invariants: rules that should always stay true. In JavaScript you can encapsulate with module scope, closure variables, WeakMaps, symbols, ordinary naming conventions, or the strongest class feature: #private fields and methods. The important part is not the punctuation. The important part is that outside code has fewer ways to create an impossible state.

Abstraction means showing the caller a smaller idea than the implementation. Callers should say thermostat.setTarget(22), not “check a range, choose the Celsius storage slot, update it, then format text for the screen.” The public method is the concept; the private field is the machinery.

Try the thermostat. Request a safe value, then request values outside the allowed range. The private field refuses to move into an invalid state because the only public path runs validation 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 it is usually simple: if several objects have the same method name, a caller can use them through that shared behavior. The caller does not need a formal interface declaration. It simply calls the method and lets the receiving object decide what happens.

The shapes playground is also an Open/Closed example. The loop is closed to modification: it always calls draw() and area(). The program is open to extension: add Triangle with the same methods, and the loop keeps working. That is more JavaScript-flavored than writing a chain of if (shape.name === ...) checks.

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 gives you more than one way to make objects. A class is great when many instances share methods on a prototype, you want instanceof to communicate identity, or you want #private fields with class syntax. A factory is just a function that returns an object. It shines when setup is conditional, when you want closure privacy, or when returning a plain object makes composition easier.

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);

The table is not a scoreboard. Use a class when shared prototype behavior and identity make the code clearer. Use a factory when you want a small creator function, closure state, or a return value that varies by input. In both cases, the caller should see a small public interface, not a pile of internals.

SOLID came from class-heavy design discussions, but the helpful parts translate well to JavaScript when you keep them lightweight. Treat the names as questions, not commandments. “How many reasons does this module have to change?” “Can I add a new kind without editing the loop?” “Can I pass a fake dependency in a test?” Those questions are useful whether your objects come from classes, factories, or modules.

Start with Single Responsibility. A class that fetches an invoice, calculates totals, formats currency, and writes HTML has four reasons to change. Split it into collaborators: one loader, one calculator, one formatter, one renderer. The code may use objects, functions, or modules; the win is that each piece is easier to test and 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}

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}

Dependency Inversion is the most test-friendly rule for front-end JavaScript. Instead of hard-coding localStorage, pass in a storage-like object. Production code can pass the browser’s storage; tests can pass a tiny in-memory 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"));

Liskov Substitution says a subtype should be usable anywhere its base type is expected without surprising the caller. The classic example is tempting: a square sounds like a special rectangle. But a mutable rectangle has two independent dimensions, while a square has one size. If setWidth() on a square secretly changes height too, code written for rectangles can get a shocking result.

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 fix is not to force the inheritance tree harder. Make the shared contract smaller. If a caller only needs area(), both objects can implement a shape interface by convention. The resizable rectangle keeps width-changing behavior; the square keeps its own invariant. Composition beats pretending every “is a” sentence should become extends.

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(", "));

Where you will use this

These principles show up anywhere a front-end program grows beyond a single script. A form field object might encapsulate validation and expose isValid(). A group of payment methods might share charge() so checkout code does not know whether the user picked a card, gift balance, or saved wallet. A table component might receive a sorting strategy instead of hard-coding one. A test might pass fake storage, fake time, or a fake analytics reporter into a class that normally talks to browser APIs.

You will also use the negative version: noticing when OOP is too much. If a module holds one helper function, it does not need a class just to look official. If two objects only share a small behavior, a mixin, plain function, or delegation can be cleaner than inheritance. If you are choosing among patterns, remember that Creational patterns and Structuring an application arrive in Stage 9; for now, prefer the smallest interface that makes change easier.

Common misconceptions

Read the explanations even when you are right. The wrong answers are common design traps.

Key takeaways

• Encapsulation protects state by forcing changes through a public interface that can validate rules.
• Abstraction gives callers a smaller idea to use: a dashboard or menu, not the engine or recipe.
• Polymorphism lets one call work across different objects, which is how Open/Closed stays practical in JavaScript.
• Factories and classes are both valid. Choose based on closure privacy, prototype sharing, this, instanceof, and clarity.
• SOLID is most useful as a set of refactoring questions: split reasons to change, avoid central branches, keep substitutions honest, depend on small capabilities, and inject dependencies.

Up next: Property flags & descriptors, where you look under every object property and learn the flags that control assignment, enumeration, and configuration.