Objects, types and functional style

01 · OBJECTS

Objects: values with names inside

So far, a value has been one thing: a number, a string. Real things have several parts. A dog has a name and an age; an order has items, a total and a status. An object keeps related values together under names, called properties. A property that holds a function is a method: something the object can do.

On the stage, rex is a box with three slots. The two tiles on the left are variables, and they are arrows, not boxes. A variable doesn't contain an object; it holds a reference to one, an address of where the object lives in memory. Copy the variable and you copy the arrow, not the object.

// An object: named values (properties) kept together
const rex = {
  name: "Rex",
  age: 3,
  speak() {                      // a function inside an object is a method
    return this.name + " says woof";
  },
};
​
console.log(rex.name);
console.log(rex.speak());
rex.age = rex.age + 1;           // objects can change after they're made
console.log(rex.age);
​
const alias = rex;               // a second name for the SAME object
alias.name = "Max";
console.log(rex.name);           // "Max": there was only ever one object
console.log(alias === rex);

That last line surprises everyone once. alias.name = "Max" renamed rex too, because there is one object with two arrows pointing at it. Most bugs with objects are really bugs about sharing, and this chapter comes back to that when it gets to immutability.

02 · CLASSES

Classes: a blueprint for objects

When you need many objects of the same shape, writing each one by hand gets old. A class is a blueprint: it says which properties every instance gets (in the constructor) and which methods they all share. new Dog("Rex", 3) builds an instance.

Watch the 3D. fido comes off the blueprint with its own name and age, but the speak() tile moves out of rex and onto the class. Methods aren't copied into each instance: there is one speak, kept on Dog.prototype, and every dog uses it. A thousand dogs, one function.

class Dog {
  constructor(name, age) {       // runs once for every new Dog
    this.name = name;
    this.age = age;
  }
  speak() {
    return this.name + " says woof";
  }
  birthday() {
    this.age++;
    return this;                 // returning this lets calls chain
  }
}
​
const rex = new Dog("Rex", 3);
const fido = new Dog("Fido", 5);
console.log(rex.speak(), "|", fido.speak());
console.log(rex.birthday().age);
console.log(Object.keys(rex));           // only the data lives on the instance
console.log(rex.speak === fido.speak);   // true: one method, shared

The code inside a class body always runs in strict mode, JavaScript's stricter dialect that turns several silent mistakes into errors. Classes arrived in ES2015; before that, people wrote the same thing with plain functions and prototypes, which is still what a class is underneath, as act 4 shows.

03 · ENCAPSULATION

Encapsulation: a shell round the data

The bigger a program, the more places could change a value by accident. Encapsulation means an object keeps its data private and lets the outside world in only through methods it chooses. The rules (no negative deposits, no overdrafts) then live in one place, and nothing can skip them.

In the 3D, the account gets a shell. #balance sits inside, locked. A call to deposit(50) comes in through a port on the front and updates the balance; a direct write from outside bounces off the shell. In JavaScript, a name that starts with # is truly private: writing acct.#balance outside the class is a SyntaxError, so the program won't even start.

class Account {
  #balance = 0;        // private: only code inside this class can touch it
​
  deposit(amount) {
    if (!(amount > 0)) throw new RangeError("deposit must be positive");
    this.#balance += amount;
  }
  withdraw(amount) {
    if (amount > this.#balance) throw new RangeError("insufficient funds");
    this.#balance -= amount;
  }
  get balance() {      // read-only view from outside
    return this.#balance;
  }
}
​
const acct = new Account();
acct.deposit(100);
acct.withdraw(30);
console.log(acct.balance);          // 70
console.log(Object.keys(acct));     // []: #balance isn't even a visible key
​
try {
  acct.withdraw(500);               // the rule is enforced in one place
} catch (e) {
  console.log(e.name + ": " + e.message);
}
console.log(acct.balance);          // still 70

Before # fields arrived in ES2022, JavaScript programmers hid data with a closure: a variable that only the functions created alongside it can see. You'll still meet this pattern everywhere:

// Before # fields, JavaScript hid data in a closure.
// count lives in makeCounter's scope; only the returned functions can see it.
function makeCounter() {
  let count = 0;
  return {
    increment() { count++; return count; },
    get value() { return count; },
  };
}
​
const c = makeCounter();
c.increment();
c.increment();
console.log(c.value);   // 2
console.log(c.count);   // undefined: there is no way in

04 · PROTOTYPES

Prototypes: how JavaScript really finds a property

Most languages with classes copy the class's layout into each object. JavaScript does something simpler and stranger: every object has a hidden link to another object, its prototype. When you read a property the object doesn't have, the engine follows the link and asks the prototype, then the prototype's prototype, until it finds the property or reaches null.

On the stage, a probe climbs that chain for five reads in turn. rex.name is found at once, on rex itself. rex.speak is one step up, on Dog.prototype. rex.eat is two up, rex.toString three, on Object.prototype, which nearly every object inherits from. rex.fly reaches null, and the answer is undefined, not an error.

const animal = {
  eat() { return this.name + " eats"; },
};
​
const dog = Object.create(animal);     // dog's prototype is animal
dog.speak = function () { return this.name + " says woof"; };
​
const rex = Object.create(dog);        // rex's prototype is dog
rex.name = "Rex";
​
console.log(rex.speak());   // not on rex: found one step up, on dog
console.log(rex.eat());     // found two steps up, on animal
console.log(rex.fly);       // not found anywhere: undefined
console.log(Object.hasOwn(rex, "name"), Object.hasOwn(rex, "speak"));
console.log(Object.getPrototypeOf(rex) === dog);

class is a friendlier syntax over exactly this. Dog extends Animal sets Dog.prototype's prototype to Animal.prototype, and a class is a function underneath. Here is the lookup the engine does on every property read, written out by hand:

class Animal { eat() { return "eats"; } }
class Dog extends Animal { speak() { return "woof"; } }
const rex = new Dog();
rex.name = "Rex";
​
// What the engine does on every property read, written out by hand:
function lookup(obj, key) {
  let steps = 0;
  for (let o = obj; o !== null; o = Object.getPrototypeOf(o)) {
    if (Object.hasOwn(o, key)) return key + ": found " + steps + " step(s) up";
    steps++;
  }
  return key + ": reached null, so undefined";
}
​
console.log(lookup(rex, "name"));
console.log(lookup(rex, "speak"));     // on Dog.prototype
console.log(lookup(rex, "eat"));       // on Animal.prototype
console.log(lookup(rex, "toString"));  // on Object.prototype
console.log(lookup(rex, "fly"));
console.log(typeof Dog);               // "function": a class is sugar

05 · COMPOSITION

Inheritance or composition

Inheritance says a thing is a kind of another thing: a Dog is an Animal, so it gets everything an Animal has. It is neat when the hierarchy is true, and painful when it isn't. Model birds, give Bird a fly(), and then meet a penguin:

class Bird {
  fly() { return "flap flap"; }
}
class Duck extends Bird {}
class Penguin extends Bird {
  fly() { throw new Error("penguins can't fly"); }   // an "is-a" that isn't
}
​
function launch(bird) {        // written for Birds, so it trusts fly()
  return bird.fly();
}
launch(new Penguin());         // Error: the hierarchy lied

Composition says a thing has abilities: build objects from small parts, and give each one only the parts it needs. On the stage the chain on the left is inheritance; on the right, a duck is assembled from canFly, canSwim and canQuack, docking one by one.

// Small behaviours, each one a function that adds methods...
const canFly = (self) => ({ fly: () => self.name + " flies" });
const canSwim = (self) => ({ swim: () => self.name + " swims" });
const canQuack = (self) => ({ quack: () => self.name + ": quack!" });
​
// ...and objects built from just the pieces they need ("has-a")
function makeDuck(name) {
  const self = { name };
  return Object.assign(self, canFly(self), canSwim(self), canQuack(self));
}
function makePenguin(name) {
  const self = { name };
  return Object.assign(self, canSwim(self));
}
​
const donald = makeDuck("Donald");
const pingu = makePenguin("Pingu");
console.log(donald.fly(), "|", donald.quack());
console.log(pingu.swim());
console.log("fly" in pingu);   // false: nothing to override, nothing to lie

"Favor object composition over class inheritance" is one of the oldest pieces of advice in the field, from the 1994 book Design Patterns. It doesn't mean never inherit. Shallow hierarchies of things that truly are kinds of each other (an HttpError extends Error) are fine. Deep trees built to share code usually aren't.

06 · POLYMORPHISM

Interfaces and polymorphism

An interface is a promise about what an object can do, with nothing about how. "A shape has an area() method that returns a number." Polymorphism (Greek for "many forms") is the payoff: code written against the promise works with every object that keeps it, including ones invented later.

The socket on the stage is the interface. A circle, a square and a plain object take turns plugging in. The call is the same every time, s.area(); the answer is different, because each object brings its own method: 3.14, 4, 3.

class Circle {
  constructor(r) { this.r = r; }
  area() { return Math.PI * this.r ** 2; }
}
class Square {
  constructor(side) { this.side = side; }
  area() { return this.side ** 2; }
}
// Not from a class at all: anything with an area() method fits.
const triangle = { base: 3, height: 2, area() { return this.base * this.height / 2; } };
​
const shapes = [new Circle(1), new Square(2), triangle];
for (const s of shapes) {
  console.log(s.constructor.name, s.area().toFixed(2));   // one call, three behaviours
}
const total = shapes.reduce((sum, s) => sum + s.area(), 0);
total.toFixed(2)

JavaScript has no interface keyword; the promise lives in your head and your docs. TypeScript makes it something a tool can check:

interface Shape {
  area(): number;
}
 
class Circle implements Shape {
  constructor(private r: number) {}
  area() { return Math.PI * this.r ** 2; }
}
 
// Structural typing: no "implements" needed, the shape of the value is enough
const shapes: Shape[] = [new Circle(1), { area: () => 4 }];
 
const bad: Shape = { size: 3 };
// error TS2353: Object literal may only specify known properties,
//               and 'size' does not exist in type 'Shape'.

Polymorphism is what replaces long chains of if (shape.type === "circle") … else if …. Every new kind of shape is a new class, not an edit to every function that handles shapes.

07 · STATIC VS DYNAMIC

Types: static or dynamic

Every value has a type: number, string, boolean, object, function. The type decides what you can do with it: you can multiply numbers, call functions, read .length of a string. The question is when a language checks that you used each value correctly.

The 3D shows types as shapes. A number is a square peg, a string is round, and add(a, b) has a square slot. On the top lane, JavaScript is dynamically typed: nothing is checked until the line runs, so the round peg reaches the slot, and add("2", 2) quietly returns "22". On the bottom lane, TypeScript is statically typed: a checker reads the code first, and its gate stops the round peg before anything runs.

function add(a, b) {
  return a + b;
}
console.log(add(2, 2));      // 4
console.log(add("2", 2));    // "22": no error, just a wrong answer
​
// Values have types; variables don't.
let x = 42;
console.log(typeof x);
x = "forty-two";
console.log(typeof x);
console.log(typeof true, typeof undefined, typeof {}, typeof add);
console.log(typeof null);    // "object": a famous 1995 bug, kept forever
​
// A dynamic language checks a line only when that line runs:
const user = { name: "Ada" };
console.log(user.name.toUpperCase());
console.log(user.email.toUpperCase());   // TypeError, but only now

A separate question is how strict a language is about mixing types. JavaScript converts freely ("2" + 2 is "22", "2" * 2 is 4). Python is dynamic too, but refuses to mix:

def add(a, b):
    return a + b
 
add(2, 2)     # 4
add("2", 2)   # TypeError: can only concatenate str (not "int") to str
              # dynamic (checked while running) but strict about mixing

Static languages include Java, C, C#, Go, Rust and TypeScript; dynamic ones include JavaScript, Python, Ruby and Lisp. Static typing catches whole classes of mistakes early and makes editors smarter (autocomplete, safe renames). Dynamic typing is quicker to start with and more flexible. Large codebases have drifted towards static checking, often by adding it to a dynamic language: TypeScript for JavaScript, type hints and mypy for Python.

08 · TYPESCRIPT

TypeScript: types for JavaScript

TypeScript is JavaScript plus type annotations. You write a: number, the TypeScript compiler (tsc) checks every use, and then it erases the types and outputs plain JavaScript. Types exist only before the program runs; the browser never sees them. That is why this page's runner, which runs JavaScript, can't run TypeScript, and the examples here are shown with the real errors tsc 5.7 prints.

function add(a: number, b: number): number {
  return a + b;
}
 
add(2, 2);     // fine
add("2", 2);
// error TS2345: Argument of type 'string' is not assignable
//               to parameter of type 'number'.
// ...reported in your editor, before the program ever runs.

You don't have to annotate everything. Type inference works types out from the values: let count = 3 is a number without you saying so, and an arrow function passed to map knows its parameter is a string. The usual habit is to annotate function parameters and let inference do the rest.

let count = 3;                  // inferred: number (no annotation needed)
count = "three";
// error TS2322: Type 'string' is not assignable to type 'number'.
 
const names = ["Ada", "Alan"];            // inferred: string[]
const lengths = names.map((n) => n.length); // inferred: number[]
// n is a string here: the editor offers .length, .toUpperCase(), ...
 
interface User {
  readonly id: number;
  name: string;
  email?: string;               // optional: string | undefined
}

How can a program know a type without running the code? It walks the parse tree from chapter 1 and works out each node's type from its children. Here is a tiny checker that does exactly that, which you can run:

// A tiny static type checker. It works out the type of an expression
// tree WITHOUT running it: what tsc does, for a much bigger language.
const env = { count: "number", name: "string", done: "boolean" };
​
function typeOf(node) {
  if (typeof node === "number") return "number";
  if (typeof node === "string" && node.startsWith('"')) return "string";
  if (typeof node === "string") {                  // a variable name
    if (!(node in env)) throw new Error("Cannot find name '" + node + "'");
    return env[node];
  }
  const l = typeOf(node.left);
  const r = typeOf(node.right);
  if (node.op === "+" && l === r && l !== "boolean") return l;
  if ("+-*".includes(node.op) && l === "number" && r === "number") return "number";
  if (node.op === "<" && l === "number" && r === "number") return "boolean";
  throw new TypeError("can't use '" + node.op + "' on " + l + " and " + r);
}
​
console.log(typeOf({ op: "*", left: "count", right: 2 }));
console.log(typeOf({ op: "+", left: "name", right: '"!"' }));
console.log(typeOf({ op: "<", left: { op: "-", left: "count", right: 1 }, right: 10 }));
try {
  typeOf({ op: "-", left: "name", right: 1 });
} catch (e) {
  console.log("rejected before running:", e.message);
}

Generics let one piece of code work for many types without forgetting which. On the stage the slot is first<T>: as each peg arrives, the slot reshapes to fit it, and TypeScript infers T from the argument. A square peg goes in and a square peg comes out, and the types say so.

// T is a type parameter: a placeholder filled in at each call
function first<T>(items: T[]): T | undefined {
  return items[0];
}
const n = first([3, 1, 2]);       // T = number,  n: number | undefined
const s = first(["a", "b"]);      // T = string,  s: string | undefined
 
// A constraint: T can be anything that HAS a length
function longest<T extends { length: number }>(a: T, b: T): T {
  return a.length >= b.length ? a : b;
}
longest("hello", "hi");           // T = string
longest([1, 2], [3]);             // T = number[]
longest(10, 20);
// error TS2345: Argument of type 'number' is not assignable
//               to parameter of type '{ length: number; }'.

One more tool takes TypeScript from helpful to powerful. A union type lists the shapes a value can have; checking a kind field narrows it to one; and the never trick makes the compiler tell you when you forgot a case:

type Shape =
  | { kind: "circle"; r: number }
  | { kind: "square"; side: number }
  | { kind: "triangle"; base: number; height: number };
 
function area(s: Shape): number {
  switch (s.kind) {
    case "circle":
      return Math.PI * s.r ** 2;    // narrowed: here s is the circle
    case "square":
      return s.side ** 2;
    default:
      const unhandled: never = s;   // forgot a case? this line won't compile
      return unhandled;
  }
}
// error TS2322: Type '{ kind: "triangle"; base: number; height: number; }'
//               is not assignable to type 'never'.

09 · PURE & IMMUTABLE

Pure functions and immutability

Functional style starts with one rule: prefer pure functions. A pure function's output depends only on its inputs, and it changes nothing outside itself: no global variables, no editing its arguments, no printing. On the stage, addTax gives 125 every time. addToTotal gives 100, then 200, then 300 for the same input, because it reads and writes total, the box underneath it.

// Pure: the output depends only on the input, and nothing else changes.
function addTax(price, rate) {
  return price * (1 + rate);
}
​
// Impure: it reads and changes something outside itself.
let total = 0;
function addToTotal(price) {
  total += price;            // a side effect
  return total;
}
​
console.log(addTax(100, 0.25), addTax(100, 0.25));   // 125 125, every time
console.log(addToTotal(100), addToTotal(100));        // 100 200: same call, new answer

The partner idea is immutability: never change a value once it exists; make a new one with the change. On the right of the stage, v2 and v3 are new boxes, each born from the one before. They all point at the same settings box, because it didn't change, so nothing was copied. That trick, structural sharing, is how immutable data stays cheap. Git stores your project history the same way: each commit is a new snapshot that reuses every file that didn't change.

const settings = { theme: "dark" };
const v1 = Object.freeze({ count: 1, settings });
​
// Don't change v1. Make a new object with the change:
const v2 = { ...v1, count: v1.count + 1 };
console.log(v1.count, v2.count);               // 1 2
console.log(v2.settings === v1.settings);       // true: unchanged parts are shared
​
v1.count = 99;              // frozen: ignored here (a TypeError in strict mode)
console.log(v1.count);      // 1
​
// Arrays: copy instead of mutate
const nums = [3, 1, 2];
const sorted = nums.toSorted();   // nums.sort() would reorder nums itself
console.log(nums, sorted);
​
// Careful: freeze is shallow
v1.settings.theme = "light";
console.log(v2.settings.theme);   // "light": both versions share that object

Real programs need side effects: saving files, drawing pixels, sending requests. The functional habit is to push them to the edges: a thin outer layer does the input and output, and a thick middle of pure functions does the thinking. Pure functions are also what makes code safe to run in parallel, on many cores or on a GPU: if nothing is shared and nothing changes, nothing can collide.

10 · MAP · FILTER · REDUCE

map, filter, reduce and composition

In JavaScript, functions are values: you can store them, pass them to other functions, and return them. A function that takes or returns functions is a higher-order function, and three of them do most of the work with lists. filter keeps the items that pass a test, map transforms each item, and reduce folds the whole list into one value.

The conveyor on the stage runs the program below. The numbers 1 to 6 enter; filter drops the odd ones through the floor; map squares what is left, 2, 4 and 6 into 4, 16 and 36; and reduce adds them into one box: 56.

const nums = [1, 2, 3, 4, 5, 6];
​
const result = nums
  .filter((n) => n % 2 === 0)        // keep the even ones: [2, 4, 6]
  .map((n) => n * n)                 // square each:        [4, 16, 36]
  .reduce((sum, n) => sum + n, 0);   // fold into one:      56
​
console.log(result);
console.log(nums);                   // untouched: each step made a new array

Compare the same job as a loop. Both are fine; the loop says how, step by step, while the pipeline says what, and each step can be read, tested and reused on its own.

// The same job, the imperative way: say HOW, step by step.
const nums = [1, 2, 3, 4, 5, 6];
let sum = 0;
for (let i = 0; i < nums.length; i++) {
  const n = nums[i];
  if (n % 2 === 0) {
    sum += n * n;
  }
}
console.log(sum);

There is no magic in them. Each is a few lines you could write yourself, and writing them once is the best way to understand them:

// map, filter and reduce are ordinary functions that take functions.
function map(arr, f) {
  const out = [];
  for (const x of arr) out.push(f(x));
  return out;
}
function filter(arr, keep) {
  const out = [];
  for (const x of arr) if (keep(x)) out.push(x);
  return out;
}
function reduce(arr, f, start) {
  let acc = start;
  for (const x of arr) acc = f(acc, x);
  return acc;
}
​
const evens = filter([1, 2, 3, 4, 5, 6], (n) => n % 2 === 0);
const squares = map(evens, (n) => n * n);
reduce(squares, (a, b) => a + b, 0)

Composition is the functional answer to building big things: join small functions into a bigger one, where the output of each is the input of the next. pipe is a one-line higher-order function that does it:

// Composition: build a big function out of small ones.
const pipe = (...fns) => (x) => fns.reduce((acc, f) => f(acc), x);
​
const trim = (s) => s.trim();
const lower = (s) => s.toLowerCase();
const dashes = (s) => s.replace(/[^a-z0-9]+/g, "-");
​
const toSlug = pipe(trim, lower, dashes);
​
console.log(toSlug("  Objects, Types & Functions "));
console.log(toSlug("Hello World"));

11 · WHICH, WHEN

Which style, when

The stage pulls back to show all six stations. The left half is object-oriented, the middle is types, the right half is functional. They answer different questions, so real programs mix them.

// One job, three styles: the total of the paid orders.
const orders = [
  { id: 1, amount: 30, paid: true },
  { id: 2, amount: 45, paid: false },
  { id: 3, amount: 25, paid: true },
];
​
// 1. Imperative: a loop and a running total
let t1 = 0;
for (const o of orders) if (o.paid) t1 += o.amount;
​
// 2. Object-oriented: the data and its rules live together
class Ledger {
  #orders;
  constructor(orders) { this.#orders = orders; }
  paidTotal() {
    let t = 0;
    for (const o of this.#orders) if (o.paid) t += o.amount;
    return t;
  }
}
const t2 = new Ledger(orders).paidTotal();
​
// 3. Functional: a pipeline of small pure steps
const t3 = orders.filter((o) => o.paid).map((o) => o.amount).reduce((a, b) => a + b, 0);
​
console.log(t1, t2, t3);

• Reach for objects when something has state that changes over time and rules that must hold: a bank account, a game character, a connection to a database, a UI widget. Encapsulation keeps the rules in one place.
• Reach for functional style when data flows in, gets transformed, and flows out: reports, search results, prices, anything you can describe as a pipeline. Pure functions are the easiest code there is to test and to run in parallel.
• Reach for static types as soon as a program will live longer than a week or be read by more than one person. They are documentation the compiler keeps honest.
• Plain imperative loops are fine for short, hot or genuinely step-by-step code. Clarity beats purity.

One more style deserves a name: declarative code says what result you want and lets something else decide how to compute it. SQL is the famous example, and the same pipeline from the conveyor looks like this in SQL and in Python:

-- Declarative: say WHAT you want; the database decides how.
SELECT SUM(n * n)
FROM nums
WHERE n % 2 = 0;      -- 56, the same pipeline as filter, map, reduce

nums = [1, 2, 3, 4, 5, 6]
sum(n * n for n in nums if n % 2 == 0)   # 56: Python's comprehension

A common modern shape is functional core, imperative shell: plain data described by types, transformed by pure functions, with a few objects at the edges owning the things that really change: the network, the screen, the database.