ProgrammationDéveloppeur Fullstack

Comment implémenter et typiser des constructeurs surchargés de classes en TypeScript ? Pourquoi ne peut-on pas simplement spécifier plusieurs méthodes constructor, et comment y parvenir correctement ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

TypeScript ne prend pas en charge plusieurs déclarations du corps du constructeur dans une classe, comme c'est le cas dans de nombreux langages OOP. Au lieu de cela, on peut déclarer plusieurs signatures de constructeur (surcharges), puis implémenter un corps de constructeur unique, où les arguments sont analysés manuellement :

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

Détails importants :

  • Dans la classe, plusieurs signatures peuvent être spécifiées au-dessus de l'implémentation, mais UNE SEULE implémentation du constructeur est autorisée.
  • L'implémentation du constructeur doit être compatible avec toutes les variantes de surcharge.
  • TypeScript vérifie lui-même la correspondance des arguments avec les surcharges.

Question piège.

« Peut-on implémenter le constructeur comme ça ? »

undefined

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


**Réponse correcte :** Non, ce code provoquera une erreur : "Duplicate constructor implementation". En TypeScript, une seule implémentation du corps du constructeur est autorisée, les surcharges doivent être présentées sous forme de signatures (sans corps).

### Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet.

---
> Histoire

Dans un projet, on a essayé d'implémenter une classe avec deux constructeurs ayant des paramètres différents — en copiant l'expérience de Java. En conséquence, TypeScript a lancé une erreur de compilation, le projet ne se compilait pas, il a fallu le refaire rapidement en utilisant des surcharges sous forme de signatures.

---
> Histoire

Un des membres de l'équipe a écrit un constructeur de classe avec surcharge, mais a oublié de prendre en compte l'optionnalité des paramètres (n'a pas géré undefined). Cela a conduit à des tentatives d'accès à des valeurs inexistantes et à des pannes lors de la création d'exemplaires avec un ensemble minimal d'arguments.

---
> Histoire

Des surcharges de constructeur ont été déclarées, mais le corps du constructeur ne correspondait pas aux variantes d'appel décrites. Dans un cas, un deuxième argument était obligatoirement attendu, alors qu'il était optionnel dans la signature. Ce conflit n'a pas été identifié immédiatement, mais il est ressorti lors de l'écriture des tests unitaires et a compliqué le débogage.