Dziedziczenie w TypeScript: extends, super i override

Klasa w TypeScript dziedziczy po innej przez extends. Podklasa dostaje każde pole i każdą metodę rodzica, wywołuje konstruktor rodzica przez super(...) i może nadpisywać metody, a TypeScript sprawdza, czy każde nadpisanie pozostaje zgodne z typami rodzica.

class Animal {
    constructor(public name: string) {}

    speak(): string {
        return `${this.name} makes a sound`;
    }
}

class Dog extends Animal {
    constructor(name: string, public breed: string) {
        super(name); // call the parent constructor first
    }

    override speak(): string {
        return `${super.speak()}: woof`; // call the parent method
    }
}

const rex = new Dog("Rex", "beagle");
console.log(rex.speak());          // Rex makes a sound: woof
console.log(rex);                  // Dog { name: 'Rex', breed: 'beagle' }
console.log(rex instanceof Animal); // true

To jest dziedziczenie klas z JavaScriptu (łańcuch prototypów, który za nim stoi, opisuje strona o dziedziczeniu w JavaScript). TypeScript dodaje sprawdzanie typów: Dog da się przypisać wszędzie, gdzie oczekiwany jest Animal, a kompilator weryfikuje nadpisanie i wywołanie super.

Nadpisywanie metod

Metoda podklasy o tej samej nazwie zastępuje metodę rodzica. Jej typ musi dać się przypisać do typu rodzica: te same lub zgodne parametry, ten sam lub węższy typ zwracany. W przeciwnym razie każdy kod, który trzyma Animal, mógłby wywołać metodę z argumentami, których podklasa nie obsłuży.

class Formatter {
    format(value: number): string {
        return value.toString();
    }
}

class CurrencyFormatter extends Formatter {
    // Compatible: accepts more (number | bigint) and returns the same type.
    override format(value: number | bigint): string {
        return `$${value.toLocaleString("en-US")}`;
    }
}

const formatters: Formatter[] = [new Formatter(), new CurrencyFormatter()];
for (const f of formatters) console.log(f.format(1234567));
// 1234567
// $1,234,567

Zmiana parametru na value: string byłaby błędem TS2416: Property 'format' in type 'CurrencyFormatter' is not assignable to the same property in base type 'Formatter'. Pętla pokazuje dlaczego: wywołuje format z liczbą na każdym elemencie, nie wiedząc, jaką ma podklasę.

Jest jedna luka. Parametry metod są porównywane biwariantnie, więc nadpisanie przyjmujące węższy typ, na przykład format(value: 1 | 2), się kompiluje, choć pętla nadal mogłaby przekazać mu 1234567. Typy zwracane są sprawdzane ściśle: zwrócenie number zamiast string to TS2416.

Słowo kluczowe override i noImplicitOverride

override mówi „ta składowa zastępuje składową klasy bazowej”, a kompilator trzyma cię za słowo. Jeśli klasa bazowa nie ma takiej składowej (literówka albo metoda, którą ktoś przemianował w rodzicu), jest to błąd:

// This does not compile: the parent has no method called 'speek'.
class Animal {
    speak(): string {
        return "...";
    }
}

class Cat extends Animal {
    override speek(): string {
        return "meow";
    }
}

console.log(new Cat().speak());

index.ts(9,14): error TS4117: This member cannot have an 'override' modifier because it is not declared in the base class 'Animal'. Did you mean 'speak'?

Bez override ta literówka się kompiluje, a speak() po cichu zwraca "...". Słowo kluczowe pomaga tylko tam, gdzie je zapisano, więc włącz noImplicitOverride w tsconfig.json. Wtedy każda metoda nadpisująca składową bazową musi to zaznaczyć, a zwykłe speak() w podklasie to błąd TS4114 (This member must have an 'override' modifier because it overrides a member in the base class 'Animal').

{
    "compilerOptions": {
        "strict": true,
        "noImplicitOverride": true
    }
}

noImplicitOverride nie wchodzi w skład strict; trzeba go dodać samodzielnie. override jest usuwane ze skompilowanego JavaScriptu.

Składowe protected w podklasach

Składowe private rodzica są w podklasie niewidoczne. Składowe protected są widoczne i właśnie po to istnieje protected: to API, które klasa nadrzędna oferuje swoim dzieciom.

class Counter {
    protected count = 0;
    private log: string[] = [];

    increment(): void {
        this.count++;
        this.log.push(`now ${this.count}`);
    }
}

class StepCounter extends Counter {
    constructor(private step: number) {
        super();
    }

    override increment(): void {
        this.count += this.step - 1; // protected: allowed
        super.increment();
        // this.log is private to Counter: a compile error here
    }

    get value(): number {
        return this.count;
    }
}

const c = new StepCounter(5);
c.increment();
c.increment();
console.log(c.value); // 10

Pełne reguły, łącznie z tym, dlaczego ani private, ani protected nie są egzekwowane w czasie wykonania, opisuje strona o modyfikatorach dostępu.

Ponowna deklaracja pola z węższym typem

Podklasa często wie, że pole przechowuje coś bardziej szczegółowego, niż mówi rodzic. Ponowna deklaracja jako pet: Dog ma przy nowoczesnych polach klas skutek w czasie wykonania: pole podklasy jest inicjalizowane wartością undefined po powrocie z super(), co kasuje to, co zapisał konstruktor rodzica. Jeśli konstruktor podklasy nie przypisze go ponownie, TypeScript zgłasza to jako TS2612 (Property 'pet' will overwrite the base property in 'Home'). Użyj declare, aby zmienić tylko typ:

class Animal {
    name = "pet";
}
class Dog extends Animal {
    bark(): string {
        return "woof";
    }
}

class Home {
    pet: Animal;
    constructor(pet: Animal) {
        this.pet = pet;
    }
}

class Kennel extends Home {
    declare pet: Dog; // type only: no field is emitted

    constructor(dog: Dog) {
        super(dog);
    }
}

console.log(new Kennel(new Dog()).pet.bark()); // woof

declare niczego nie generuje, więc wartość ustawiona przez konstruktor Home przetrwa. To konstruktor przyjmujący tylko Dog sprawia, że węższy typ jest prawdziwy.

implements a extends

Te dwa słowa kluczowe odpowiadają na różne pytania, a klasa może używać obu.

interface Serializable {
    serialize(): string;
}

class Entity {
    constructor(readonly id: number) {}
}

class User extends Entity implements Serializable {
    constructor(id: number, readonly email: string) {
        super(id);
    }

    serialize(): string {
        return JSON.stringify({ id: this.id, email: this.email });
    }
}

const u = new User(1, "ada@example.com");
console.log(u.serialize()); // {"id":1,"email":"ada@example.com"}

Klasa może rozszerzać tylko jedną klasę (TS1174: Classes can only extend a single class). Aby połączyć zachowanie z kilku miejsc, zaimplementuj kilka interfejsów i współdziel kod przez kompozycję (pole przechowujące obiekt pomocniczy) albo mixiny.

Mixiny

Mixin to funkcja, która przyjmuje klasę i zwraca jej podklasę. Daje to formę wielokrotnego dziedziczenia, która przechodzi sprawdzanie typów:

type Constructor<T = {}> = new (...args: any[]) => T;

function Timestamped<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        createdAt = new Date("2024-03-15T10:30:00Z");
    };
}

function Tagged<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        tags: string[] = [];
        tag(t: string): this {
            this.tags.push(t);
            return this;
        }
    };
}

class Note {
    constructor(public text: string) {}
}

const TaggedNote = Tagged(Timestamped(Note));
const n = new TaggedNote("buy milk").tag("home");
console.log(n.text, n.tags, n.createdAt.toISOString());
// buy milk [ 'home' ] 2024-03-15T10:30:00.000Z

any[] w Constructor jest wymagane: TypeScript akceptuje jako bazę mixinu tylko klasę, której konstruktor przyjmuje jeden parametr rest typu any[]. Mixiny działają, ale utrudniają czytanie typów i śladów stosu, więc najpierw sięgaj po kompozycję.

Typowe błędy

• Wywoływanie nadpisywalnej metody z konstruktora bazowego. Konstruktor bazowy działa, zanim pola podklasy zostaną zainicjalizowane, więc nadpisanie, które czyta this.items, widzi undefined, a wywołanie takie jak this.items.push(x) rzuca TypeError w czasie wykonania. TypeScript tego nie wyłapuje.
• Brak super(...) albo wywołanie go za późno. Błędy TS2377 i TS17009; rodzic musi zbudować obiekt, zanim podklasa dotknie this.
• Ponowna deklaracja pola rodzica bez declare. Pole podklasy resetuje je do undefined.
• Głębokie hierarchie. Każdy poziom wiąże dziecko z wnętrzem rodzica. Zwykle wystarczą dwa poziomy; dalej lepiej sięgnąć po kompozycję lub interfejsy.