ProgrammierungFullstack Entwickler

Wie implementiert und typisiert man überladene Konstruktoren von Klassen in TypeScript? Warum kann man nicht einfach mehrere Konstruktor-Methoden angeben, und wie erreicht man dies korrekt?

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort.

TypeScript unterstützt nicht mehrere Konstruktor-Methoden innerhalb einer Klasse, wie es in vielen OOP-Sprachen möglich ist. Stattdessen kann man mehrere Konstruktor-Signaturen (Überladungen) deklarieren und dann einen einheitlichen Konstruktor-Body implementieren, in dem die Argumente manuell analysiert werden:

class User { name: string; age: number; constructor(name: string); constructor(name: string, age: number); constructor(name: string, age?: number) { this.name = name; this.age = age ?? 18; } } const u1 = new User('Alice'); // age = 18 const u2 = new User('Bob', 32); // age = 32

Wichtige Details:

  • In der Klasse können mehrere Signaturen über der Implementierung angegeben werden, aber nur EINE Implementierung des Konstruktors ist erlaubt.
  • Die Implementierung des Konstruktors muss mit allen Varianten der Überladung kompatibel sein.
  • TypeScript überprüft selbstständig die Übereinstimmung der Argumente mit den Überladungen.

Fangfrage.

„Kann man den Konstruktor so implementieren?“

undefined

class Test { constructor(x: number) {} constructor(x: string) {} }


**Richtige Antwort:** Nein, dieser Code führt zu einem Fehler: "Duplicate constructor implementation". In TypeScript ist nur eine Implementierung des Konstruktors erlaubt, Überladungen werden in Form von Signaturen (ohne Body) dargestellt.

### Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---
> Geschichte

In einem Projekt wurde versucht, eine Klasse mit zwei Konstruktoren mit unterschiedlichen Parametern — angelehnt an Java — zu implementieren. Das führte dazu, dass TypeScript einen Kompilierungsfehler ausgab, das Projekt nicht kompiliert werden konnte, und die Implementierung schnell auf Überladungen in Signaturen umgeschrieben werden musste.

---
> Geschichte

Ein Teammitglied schrieb einen Klassenkonstruktor mit Überladung, vergass jedoch die Optionalität der Parameter zu berücksichtigen (vereinigte undefined nicht). Dies führte zu Versuchen, auf nicht existierende Werte zuzugreifen, und zu Abstürzen bei der Erstellung von Instanzen mit einem minimalen Argumentensatz.

---
> Geschichte

Es wurden Überladungen des Konstruktors deklariert, aber der Body des Konstruktors stimmte nicht mit den beschriebenen Aufrufvarianten überein. In einem Fall wurde ein zweites Argument zwingend erwartet, während es in der Signatur optional war. Dieser Konflikt wurde nicht sofort erkannt, tauchte jedoch beim Schreiben von Unit-Tests auf und erschwerte das Debugging.