beginner25 minby DevFox

Classes and Objects

Fields, constructors, methods and access modifiers; how a class is both a value and a type; and the many problems a plain function and an object type solve better.

TypeScript

You have a Photo type and eleven functions that all take one as their first argument. caption(photo), isLarge(photo), resize(photo, width). The data and the things you do to it live in different places, and every new operation is another function with the same first parameter.

A class puts them together. By the end of this lesson you will write one, know what the access modifiers actually protect, and — because this matters more than the syntax — know the several common cases where a class is the wrong answer.

Data and behaviour together

typescript

class Photo {
  constructor(
    public readonly name: string,
    public readonly city: string,
    public size: number,
  ) {}

  caption(): string {
    return `${this.name.replaceAll("_", " ")}, ${this.city}`;
  }

  isLarge(): boolean {
    return this.size > 1000;
  }
}

typescript

const photo = new Photo("sunrise_over_lisbon.jpg", "Lisbon", 1450);

photo.caption();      // "sunrise over lisbon.jpg, Lisbon"
photo.isLarge();      // true
photo.size = 1600;    // allowed - not readonly
photo.name = "x";     // error - readonly

A class describes a kind of thing. new Photo(...) builds one, called an instance. Functions inside are methods, and this refers to the instance the method was called on.

That constructor form is worth pointing out. Writing public or readonly on a constructor parameter declares the property and assigns it in one step. The longhand is:

typescript

class Photo {
  readonly name: string;

  constructor(name: string) {
    this.name = name;
  }
}

The short form is standard and removes the repetition of naming every field three times.

What the modifiers do

typescript

class Photo {
  public name: string;        // the default - reachable from anywhere
  private key: string;        // only inside this class
  protected raw: Buffer;      // this class and its subclasses
  readonly id: string;        // cannot be reassigned after construction
}

private is checked at compile time and erased. At runtime the property is an ordinary one, reachable by anyone who looks:

typescript

photo.key;              // error from the checker
(photo as any).key;     // works at runtime

For genuine privacy there is a separate mechanism with a # prefix:

typescript

class Photo {
  #apiKey: string;

  constructor(key: string) {
    this.#apiKey = key;
  }
}

photo.#apiKey;          // a syntax error outside the class - always

private key: string

Compile-time only. Erased.

At runtime it is an ordinary property, so (photo as any).key reads it and JSON.stringify includes it.

Right for stating design intent — this is not part of the public surface.

#apiKey: string

Genuinely inaccessible, at runtime too.

Reading it from outside the class is a syntax error, not a type error, so no cast can get around it.

Right when the value must not be reachable regardless of what somebody writes.

Both stop a colleague reaching in. Only one stops an attacker.

Getters, and computed values

A getter is a method called as though it were a field. The value is computed each time, so it cannot go stale — which is the main reason to use one, for anything derived from other fields.

A setter can validate on assignment:

Keep getters cheap. Something that reads as a property and takes a second is a surprise, and the caller has no way to know.

Extending, carefully

extends means RawPhoto gets everything Photo has. super(...) runs the parent's constructor and must be called before using this. super.caption() calls the parent's version rather than replacing it.

override is a keyword worth turning on with "noImplicitOverride": true: it makes the checker verify that you are actually overriding something, so renaming a method in the parent produces an error rather than a subclass method that is silently never called.

Inheritance is genuinely useful and routinely overused. The question is whether the child is a kind of the parent and can be used anywhere the parent can. A RawPhoto is a Photo, so this is fine. class PhotoDatabase extends Photo because the database contains photos is not — a database is not a kind of photo, and inheriting gives it every photo method, none of which make sense.

When unsure, hold an object rather than inheriting from it.

When a class is the wrong answer

Bad — a class that is a function wearing a costume.

Good — a function.

The class holds no state that lives between calls — separator is an argument moved somewhere less visible. So the object exists only to be constructed and immediately used: two steps and an extra name to do what one call does. It is also harder to import, harder to test, and cannot be passed to map without wrapping.

Three tests catch nearly every class that should not have been one, and each points at what to write instead.

Constructor plus one method

That is a function.

Nothing lives between calls, so the object exists only to be constructed and immediately used.

It is also harder to import, harder to test, and cannot be passed to map without wrapping.

Data with no behaviour

A type and a plain object.

Same checking, less ceremony — and a plain object can be spread, serialised with JSON.stringify and compared field by field. A class instance does none of those as cleanly.

Methods that never touch this

That is a module.

A class you never instantiate, holding static methods, is a module with extra punctuation around it.

Use a class when data and behaviour belong together and the data outlives a single call

Classes as types

A class declaration creates a value and a type:

The type is structural, like everything else — anything with the right shape satisfies it, whether or not it came from that class. implements is a check that a class has what a type requires, reported where you wrote it:

And instanceof narrows a union, which is how classes fit the narrowing lesson:

That is the one place classes are clearly better than plain objects: errors, where instanceof gives you a reliable check that survives being thrown across a call stack.

A cheat sheet to keep

Where to go next

You can now define a type of your own carrying data and behaviour, control what is reachable, and extend one class from another. Just as valuable, you have three tests for when not to — because most code here is functions, types and modules, with classes where they earn their place.

Next is Errors and Exceptions, which is where classes turn out to be genuinely the right tool. It covers throwing and catching, why a caught value is unknown rather than an Error, and the empty catch block that turns a bug into a mystery.

Before you move on, take a group of values your code passes around with several functions operating on them, and write it both ways — as a class with methods, and as a type with functions. Then look honestly at which reads better. Sometimes it is the class; often it is not, and noticing that is the skill this lesson is actually teaching.