Classes: Types You Design Yourself

Chapter 12’s Book type describes a shape. Chapter 13 then showed that anyone holding one of those objects can reach in and change any field they like, and chapter 14’s project depended on you remembering to spread before sorting.

There’s a pattern in all of that: the data is in one place and the rules about it are somewhere else, in your head.

A class

class Counter {
  count = 0;

  increment(): void {
    this.count = this.count + 1;
  }

  describe(): string {
    return `count is ${this.count}`;
  }
}

A class is a description of a kind of thing: what it holds, and what it can do. count is a field, the same as a property on an object. increment and describe are methods, which are functions that live inside the class.

Making one needs new:

const c = new Counter();
c.increment();
c.increment();

console.log(c.count);
console.log(c.describe());

2
count is 2

new Counter() builds a fresh counter with count at 0. Every one you make is separate, so two counters count independently.

this

Inside a method, this means “the object this method was called on”.

c.increment() runs increment with this being c. Call it on a different counter and this is that one instead. It’s how one piece of code written once works on every object of that class.

You need this every time you touch a field. Writing count = count + 1 inside the method doesn’t work, TypeScript will tell you count doesn’t exist, because a bare name means a variable and fields aren’t variables.

Why bother, given chapter 12

You could write all of that with a type and some functions, and for a counter you probably should. Two things change as the thing gets bigger.

The functions live with the data. c.describe() is findable from c. A describe(c) function could be in any file in the project, and there’s nothing about the object that points at it.

You can decide what’s off limits. That’s the part a type genuinely cannot do.

private

class Account {
  private balance = 100;

  getBalance(): number {
    return this.balance;
  }
}

const a = new Account();
console.log(a.balance);

error TS2341: Property 'balance' is private and only accessible
within class 'Account'.

private means “inside this class only”. Methods of Account can use balance freely; nothing else can, and TypeScript enforces it.

That matters because a balance isn’t just a number, it’s a number with rules. Money moves in and out through deposits and withdrawals, both of which might need checking. Leave the field public and any line anywhere can set it to -4000 and skip every rule you wrote.

Making it private means there is exactly one door in, the methods you wrote on purpose, and all your rules can live behind it.

Actually private

JavaScript has its own private fields, and they survive to runtime. They’re spelled with a #:

class Account {
  #balance = 100;

  getBalance(): number {
    return this.#balance;
  }
}

const a = new Account();
console.log(a.getBalance());
console.log(a);

100
Account {}

Account {}. The field isn’t hidden from you by politeness, it genuinely cannot be reached from outside, and there’s no cast that gets around it. Object.keys(a) gives an empty list and JSON.stringify(a) gives {}.

The # is part of the name, so it’s this.#balance everywhere, every time. That looks strange for about a day.

Which to use. private reads better and is what most TypeScript code uses, because in a codebase where everything is checked, a compile-time rule is enough. Use # when the privacy has to be real: something a mistake outside your code could genuinely corrupt, or anything that will be handed to code that isn’t type-checked.

This book uses # from here on, because a chapter about enforcing your own rules should use the version that actually enforces them.

class Deck {
  #cards: string[] = [];

  fill(): void { }
  size(): number { }
  deal(): string | undefined { }
  shuffle(): void { }
}

const d = new Deck();
d.fill();
console.log(d.size());
console.log(d);

const empty = new Deck();
console.log(empty.size(), empty.deal());

0 undefined