interface oder type: drei Stellen, an denen es zählt

Was tatsächlich gleich ist

Beide Schreibweisen beschreiben Objektformen, und der Compiler behandelt das Ergebnis in aller Regel gleich. Beide lassen sich mit Typparametern versehen, beide funktionieren mit implements an einer Klasse, beide erlauben optionale und nur lesbare Felder, beide lassen sich erweitern: interface mit extends, ein Typalias über das Und-Zeichen. Ein interface kann auch von einem Typalias erben, solange dieser eine Objektform beschreibt, und umgekehrt lässt sich ein interface in eine Zusammenführung aufnehmen. Die beiden Welten sind also nicht getrennt, sondern beschreiben in weiten Teilen dasselbe mit anderer Schreibweise.

Auch der oft genannte Unterschied bei der Lesbarkeit von Fehlermeldungen ist kleiner, als er dargestellt wird. Ein benannter Typ erscheint in Meldungen unter seinem Namen, gleich in welcher Form er deklariert wurde. Wirklich unterschiedlich wird es erst bei Zusammenführungen mit dem Und-Zeichen: Die erscheinen in Meldungen häufig ausgeschrieben als Verknüpfung mehrerer Typen, während eine Erweiterung mit extends unter dem Namen des erweiterten Typs bleibt. Wer viele solcher Verknüpfungen hat, merkt das beim Lesen der Ausgabe.

Das Zusammenführen gleichnamiger Deklarationen

Schreibst du zweimal interface Kunde in denselben Bereich, entsteht kein Fehler, sondern ein Typ mit den Feldern aus beiden Deklarationen. Innerhalb einer Datei ist das fast immer ein Versehen und ein guter Grund, es sich abzugewöhnen. Über Modulgrenzen hinweg ist es dagegen das einzige Mittel, um fremde Typdeklarationen zu erweitern. Der übliche Fall: Eine Bibliothek für Server hängt an ihr Anfrageobjekt weitere Felder, sobald bestimmte Zusatzmodule eingebunden sind, und dein Code soll diese Felder kennen. Du schreibst dazu einen declare-module-Block mit einem gleichnamigen interface und deinem zusätzlichen Feld, und ab dann kennt der Compiler es überall.

Mit einem Typalias geht das nicht, dort meldet der Compiler einen doppelten Bezeichner. Es gibt auch keinen Umweg über eine Zusammenführung, weil die Erweiterung ja am ursprünglichen Namen ansetzen muss und nicht an einem neuen. Das ist der eine Fall, in dem eine Teamregel gegen interface tatsächlich blockiert, und er kommt in jedem Projekt vor, das eine Bibliothek für Server oder ein Testwerkzeug typisiert erweitert.

Dieselbe Eigenschaft hat eine unerwartete Nebenwirkung, die den dritten wichtigen Unterschied erklärt. Weil ein interface jederzeit von außen erweitert werden könnte, betrachtet der Compiler seine Feldliste als nicht abschließend. Ein Typalias für dieselbe Form gilt dagegen als vollständig bekannt und bekommt deshalb eine implizite Indexsignatur. Praktisch heißt das: Ein Wert mit einem Typalias lässt sich an einen Parameter vom Typ Record mit beliebigen Schlüsseln übergeben, ein gleich aussehendes interface nicht. Die Meldung dazu nennt weder das Wort interface noch die Erweiterbarkeit, und deshalb kostet sie beim ersten Mal verlässlich eine halbe Stunde.

extends gegen das Und-Zeichen

Beide Wege fügen Felder hinzu, aber sie melden Widersprüche zu verschiedenen Zeitpunkten. Erweiterst du ein interface mit extends und deklarierst dabei ein Feld, das im Ausgangstyp einen anderen Typ hat, meldet der Compiler das sofort an der Deklaration. Führst du zwei Typaliase mit dem Und-Zeichen zusammen, bleibt die Deklaration still: Bei zwei unverträglichen einfachen Typen wird das Feld zu never, bei zwei Objekttypen entsteht eine Verschneidung, die kein Wert mehr erfüllen kann, und bei zwei Funktionstypen eine Überladung aus beiden Signaturen. Auffällig wird das erst dort, wo jemand einen Wert zuweisen will, und die Meldung erscheint dann an einer Stelle, die mit der Ursache nichts zu tun hat.

Der zweite Unterschied betrifft den Compiler selbst. Eine Erweiterung mit extends ergibt einen benannten, flachen Typ, den der Compiler zwischenspeichern und bei jedem weiteren Vergleich wiederverwenden kann. Eine tief verschachtelte Verknüpfung mit dem Und-Zeichen muss dagegen bei jedem Vergleich neu abgearbeitet werden. In kleinen Projekten merkt das niemand. In großen, wo dieselben Verknüpfungen an hunderten Stellen auftauchen, ist das ein spürbarer Anteil an der Dauer eines Prüflaufs, und die Projektdokumentation von TypeScript empfiehlt für diesen Fall ausdrücklich die Erweiterung statt der Verknüpfung.

Eine Teamregel, die trägt

Eine Regel, die in der Praxis funktioniert, hat drei Teile. Erstens: Für Objektformen, die nach außen sichtbar sind und von anderen Modulen benutzt werden, nimmst du eine der beiden Formen durchgehend. Welche, ist zweitrangig, wichtig ist die Einheitlichkeit, denn danach sieht dieselbe Sache im ganzen Projekt gleich aus. Zweitens: Für alles, was keine reine Objektform ist, also Vereinigungen, Tupel, Funktionstypen und alles Abgeleitete, nimmst du type, weil es keine Alternative gibt. Und drittens: Für Erweiterungen fremder Deklarationen nimmst du interface, aus demselben Grund.

Damit die Regel nicht in einem Dokument versauert, das niemand liest, gehört sie in die Linter-Konfiguration. typescript-eslint hat dafür die Regel consistent-type-definitions, die sich auf eine der beiden Formen festlegen lässt und die andere für gewöhnliche Objektformen meldet. Die Sonderfälle stören dabei nicht, weil eine Vereinigung ohnehin kein interface sein kann und deshalb gar nicht geprüft wird.

Was du dir sparen kannst, ist eine Umstellung des Bestands. Der Gewinn einer einheitlichen Schreibweise entsteht beim Lesen neuer Deklarationen, nicht dadurch, dass alte umgeschrieben werden. Ein Massenumbau erzeugt einen großen Änderungssatz ohne fachlichen Inhalt, verdeckt in der Versionsgeschichte alles Übrige und bringt in genau einem Fall sogar echten Ärger: dort, wo ein interface bisher über eine Zusammenführung erweitert wurde und diese Erweiterung nach der Umstellung stillschweigend nicht mehr greift.