TypeScript Vererbung: extends, super und override

Eine TypeScript-Klasse erbt mit extends von einer anderen. Die Unterklasse bekommt jedes Feld und jede Methode der Elternklasse, ruft den Elternkonstruktor mit super(...) auf und kann Methoden überschreiben, und TypeScript prüft, dass jede Überschreibung zu den Typen der Elternklasse kompatibel bleibt.

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

Das ist Klassenvererbung von JavaScript (die Prototypkette dahinter steht unter Vererbung in JavaScript). TypeScript ergänzt die Typprüfungen: Ein Dog ist überall zuweisbar, wo ein Animal erwartet wird, und der Compiler prüft die Überschreibung und den Aufruf von super.

Methoden überschreiben

Eine gleichnamige Methode der Unterklasse ersetzt die der Elternklasse. Ihr Typ muss dem der Elternklasse zuweisbar sein: gleiche oder kompatible Parameter, gleicher oder engerer Rückgabetyp. Sonst könnte jeder Code, der ein Animal hält, die Methode mit Argumenten aufrufen, die die Unterklasse nicht verarbeiten kann.

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

Den Parameter auf value: string zu ändern wäre der Fehler TS2416: Property 'format' in type 'CurrencyFormatter' is not assignable to the same property in base type 'Formatter'. Die Schleife zeigt, warum: Sie ruft format bei jedem Element mit einer Zahl auf, ohne zu wissen, welche Unterklasse sie vor sich hat.

Es gibt eine Lücke. Methodenparameter werden bivariant verglichen, also kompiliert eine Überschreibung, die einen engeren Typ akzeptiert, etwa format(value: 1 | 2), obwohl die Schleife ihr weiterhin 1234567 übergeben könnte. Rückgabetypen werden streng geprüft: number statt string zurückzugeben ist TS2416.

Das Schlüsselwort override und noImplicitOverride

override sagt: Dieser Member ersetzt einen der Basisklasse, und der Compiler nimmt dich beim Wort. Hat die Basis keinen solchen Member (ein Tippfehler oder eine Methode, die jemand in der Elternklasse umbenannt hat), ist das ein Fehler:

// 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'?

Ohne override kompiliert dieser Tippfehler, und speak() gibt stillschweigend "..." zurück. Das Schlüsselwort hilft nur dort, wo es steht, schalte also noImplicitOverride in tsconfig.json ein. Dann muss jede Methode, die einen Basismember überschreibt, das angeben, und ein einfaches speak() in einer Unterklasse ist der Fehler TS4114 (This member must have an 'override' modifier because it overrides a member in the base class 'Animal').

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

noImplicitOverride gehört nicht zu strict; du musst es selbst hinzufügen. override wird aus dem kompilierten JavaScript entfernt.

protected Member in Unterklassen

private Member der Elternklasse sind in der Unterklasse unsichtbar. protected Member sind sichtbar, und genau deshalb gibt es protected: Es ist die API, die eine Elternklasse ihren Kindern anbietet.

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

Die vollständigen Regeln stehen unter Zugriffsmodifikatoren, auch warum weder private noch protected zur Laufzeit durchgesetzt wird.

Ein Feld mit engerem Typ neu deklarieren

Eine Unterklasse weiß oft, dass ein Feld etwas Spezifischeres enthält, als die Elternklasse sagt. Es als pet: Dog neu zu deklarieren hat mit modernen Klassenfeldern eine Wirkung zur Laufzeit: Das Feld der Unterklasse wird nach dem Ende von super() mit undefined initialisiert und löscht, was der Elternkonstruktor gespeichert hat. Weist der Konstruktor der Unterklasse es nicht erneut zu, meldet TypeScript das als TS2612 (Property 'pet' will overwrite the base property in 'Home'). Nimm declare, um nur den Typ zu ändern:

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 erzeugt nichts, also bleibt der vom Konstruktor von Home gesetzte Wert erhalten. Der Konstruktor, der nur ein Dog akzeptiert, macht den engeren Typ wahr.

implements vs extends

Die beiden Schlüsselwörter beantworten unterschiedliche Fragen, und eine Klasse kann beide verwenden.

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"}

Eine Klasse kann nur eine Klasse erweitern (TS1174: Classes can only extend a single class). Um Verhalten aus mehreren Quellen zu kombinieren, implementiere mehrere Interfaces und teile Code über Komposition (ein Feld mit einem Hilfsobjekt) oder Mixins.

Mixins

Ein Mixin ist eine Funktion, die eine Klasse nimmt und eine Unterklasse davon zurückgibt. Das ergibt eine Form von Mehrfachvererbung, die die Typprüfung besteht:

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

Das any[] in Constructor ist Pflicht: TypeScript akzeptiert als Basis eines Mixins nur einen Konstruktor, der einen einzigen Rest-Parameter vom Typ any[] nimmt. Mixins funktionieren, machen Typen und Stacktraces aber schwerer lesbar, greife also zuerst zur Komposition.

Häufige Fehler

• Eine überschreibbare Methode im Basiskonstruktor aufrufen. Der Basiskonstruktor läuft, bevor die Felder der Unterklasse initialisiert sind, also sieht eine Überschreibung, die this.items liest, undefined, und ein Aufruf wie this.items.push(x) wirft zur Laufzeit einen TypeError. TypeScript findet das nicht.
• super(...) vergessen oder zu spät aufrufen. Fehler TS2377 und TS17009; die Elternklasse muss das Objekt bauen, bevor die Unterklasse this berührt.
• Ein Feld der Elternklasse ohne declare neu deklarieren. Das Feld der Unterklasse setzt es auf undefined zurück.
• Tiefe Hierarchien. Jede Ebene koppelt das Kind an die Interna der Elternklasse. Zwei Ebenen reichen meist; darüber hinaus sind Komposition oder Interfaces besser.