TypeScript abstrakte Klasse: Methoden, Eigenschaften, vs Interface

Eine abstrakte Klasse ist eine als abstract markierte Basisklasse. Sie kann nicht mit new erzeugt werden, und sie kann abstract Methoden ohne Rumpf deklarieren, die jede Unterklasse implementieren muss.

abstract class Shape {
    abstract area(): number; // no body: subclasses provide it

    describe(): string {
        // Concrete methods can call abstract ones.
        return `${this.constructor.name} with area ${this.area().toFixed(2)}`;
    }
}

class Circle extends Shape {
    constructor(private r: number) {
        super();
    }
    area(): number {
        return Math.PI * this.r ** 2;
    }
}

class Rect extends Shape {
    constructor(private w: number, private h: number) {
        super();
    }
    area(): number {
        return this.w * this.h;
    }
}

const shapes: Shape[] = [new Circle(1), new Rect(2, 3)];
for (const s of shapes) console.log(s.describe());
// Circle with area 3.14
// Rect with area 6.00

Shape teilt describe() mit jeder Unterklasse und zwingt jede, area() bereitzustellen. Der Typ Shape[] fasst jede Mischung aus Unterklassen.

Eine abstrakte Klasse kann nicht instanziiert werden

new auf einer abstrakten Klasse aufzurufen ist ein Compilerfehler, denn das Objekt hätte Methoden ohne Implementierung:

// This does not compile: Shape is abstract.
abstract class Shape {
    abstract area(): number;
}

const s = new Shape();
console.log(s.area());

index.ts(6,11): error TS2511: Cannot create an instance of an abstract class.

Das ist eine Regel beim Kompilieren. abstract wird aus der Ausgabe entfernt, das erzeugte Shape ist also eine gewöhnliche JavaScript-Klasse, und untypisierter JavaScript-Code könnte weiterhin new Shape() aufrufen. Braucht eine Bibliothek einen Schutz zur Laufzeit, kann der Konstruktor new.target prüfen:

abstract class Plugin {
    constructor() {
        if (new.target === Plugin) {
            throw new TypeError("Plugin is abstract; extend it");
        }
    }
    abstract run(): string;
}

class Hello extends Plugin {
    run(): string {
        return "hello";
    }
}

console.log(new Hello().run()); // hello

Abstrakte Methoden und Eigenschaften

Eine Unterklasse muss jeden abstrakten Member implementieren oder selbst abstrakt sein. Fehlt einer, ist das der Fehler TS2515, der etwa lautet Non-abstract class 'Square' does not implement inherited abstract member area from class 'Shape', oder TS2654, der alle aufzählt, wenn mehrere fehlen.

Felder, Getter und Methoden können alle abstrakt sein, und sie können protected sein:

abstract class Report {
    abstract readonly title: string;          // abstract property
    protected abstract rows(): string[];      // only for subclasses

    abstract get footer(): string;            // abstract getter

    render(): string {
        return [this.title, ...this.rows(), this.footer].join("\n");
    }
}

class SalesReport extends Report {
    readonly title = "Sales Q1";

    protected rows(): string[] {
        return ["Jan: 120", "Feb: 95", "Mar: 140"];
    }

    get footer(): string {
        return "Total: 355";
    }
}

console.log(new SalesReport().render());

Eine abstrakte Methode hat keinen Rumpf; einen zu schreiben ist der Fehler TS1245 (Method 'x' cannot have an implementation because it is marked abstract). Eine abstrakte Klasse muss überhaupt keine abstrakten Member haben: abstract allein verhindert nur die direkte Instanziierung.

Das Template-Method-Muster

Der häufigste Grund für eine abstrakte Klasse: Die Basisklasse legt die Reihenfolge der Schritte fest, und jede Unterklasse füllt die Schritte aus, die sich unterscheiden.

abstract class Importer<T> {
    // The algorithm lives here, once.
    import(raw: string): T[] {
        const lines = raw.trim().split("\n");
        const records = lines.map((line) => this.parse(line));
        return records.filter((r) => this.isValid(r));
    }

    protected abstract parse(line: string): T;

    // A default subclasses may override.
    protected isValid(_record: T): boolean {
        return true;
    }
}

type Person = { name: string; age: number };

class PersonImporter extends Importer<Person> {
    protected parse(line: string): Person {
        const [name, age] = line.split(",");
        return { name, age: Number(age) };
    }

    protected override isValid(p: Person): boolean {
        return !Number.isNaN(p.age);
    }
}

console.log(new PersonImporter().import("Ada,36\nBob,x\nCy,29"));
// [ { name: 'Ada', age: 36 }, { name: 'Cy', age: 29 } ]

Abstrakte Klassen können generisch sein, wie hier, sodass jede Unterklasse den Datensatztyp wählt.

Abstrakte Konstruktortypen

typeof Shape ist bei einer abstrakten Klasse ein Konstruktor, den du nicht aufrufen darfst, ein Parameter vom Typ typeof Shape kann also kein new c() ausführen. Soll eine Funktion abstrakte Klassen akzeptieren (etwa um sie zu registrieren oder instanceof zu prüfen), typisierst du sie mit einer abstrakten Construct Signature:

abstract class Animal {
    abstract sound(): string;
}
class Dog extends Animal {
    sound(): string {
        return "woof";
    }
}

type AbstractCtor<T> = abstract new (...args: never[]) => T;
type Ctor<T> = new () => T;

function isKind<T>(value: unknown, kind: AbstractCtor<T>): value is T {
    return value instanceof kind;
}

function create<T>(kind: Ctor<T>): T {
    return new kind();
}

const pet = create(Dog);     // fine: Dog is concrete
console.log(pet.sound());    // woof
console.log(isKind(pet, Animal), isKind("cat", Animal)); // true false
// create(Animal) is an error: Animal is abstract

abstract new akzeptiert abstrakte und konkrete Klassen; einfaches new akzeptiert nur konkrete.

Abstrakte Klasse vs Interface

Die Faustregel: ein Interface, wenn du nur eine Form beschreiben musst (der häufigste Fall, und er funktioniert auch für Objektliterale), eine abstrakte Klasse, wenn Unterklassen echte Implementierung teilen und der Compiler sie zwingen soll, die Lücken zu füllen. Beides lässt sich gut kombinieren: ein Interface für den öffentlichen Vertrag, eine abstrakte Klasse als bequeme Basis, die es implementiert. Den anderen häufigen Vergleich findest du unter interface vs type.

Häufige Fehler

• Eine abstrakte Klasse verwenden, wo ein Interface reicht. Hat die Basisklasse keinen Code, ist sie ein Interface mit zusätzlichem Gewicht zur Laufzeit und der Grenze der Einfachvererbung.
• static abstract versuchen. Nicht erlaubt. Statische Member können nicht abstrakt sein.
• Einen Laufzeitfehler bei new auf einer abstrakten Klasse erwarten. Es gibt keinen, außer du schreibst die Prüfung mit new.target.
• Eine abstrakte Methode im Basiskonstruktor aufrufen. Sie läuft, bevor die Felder der Unterklasse initialisiert sind, also sieht die Implementierung sie als undefined.