Réponse.

Contexte de la question

De nombreux langages strictement typés (C++, C#, Python) permettent une description explicite des surcharges pour les opérateurs (par exemple, +, -, *, ==) au niveau de la classe. En TypeScript, tout comme en JavaScript, la surcharge d'opérateurs est absente au niveau du langage pour des raisons historiques et architecturales.

Problème

Lorsqu'il est nécessaire d'ajouter un support pour l'arithmétique ou d'autres opérations pour des types complexes (par exemple, des nombres complexes ou des vecteurs), il est impossible de modifier les opérateurs standard. Cela limite l'expressivité et nécessite d'inventer des modèles de contournement.

Solution

En TypeScript, la surcharge des opérateurs est simulée via des méthodes spécifiquement nommées (par exemple, add, equals, multiply). Équipant la classe de telles méthodes, nous mettons en œuvre un comportement typé, bien que la syntaxe ne soit pas aussi concise que celle en C++.

Exemple de code :

class Vector {
    constructor(public x: number, public y: number) {}
    add(other: Vector): Vector {
        return new Vector(this.x + other.x, this.y + other.y);
    }
    equals(other: Vector): boolean {
        return this.x === other.x && this.y === other.y;
    }
}

const a = new Vector(1, 2);
const b = new Vector(3, 4);
const c = a.add(b); // Vector { x: 4, y: 6 }
const eq = a.equals(b); // false

Caractéristiques clés :

• La surcharge d'opérateurs n'est pas possible au niveau de la syntaxe
• Utilisez des méthodes avec des noms explicites (par exemple, add, sub, equals)
• Le typage des méthodes assure la sécurité des opérations

Questions pièges.

Peut-on redéfinir le comportement de l'opérateur "==" ou "+" pour une classe personnalisée en TypeScript ?

Non, JavaScript (et TypeScript) ne permet pas de surcharger directement les opérateurs standard pour des objets personnalisés. Les opérateurs sont appliqués strictement selon la norme pour Object, Number et d'autres primitifs. Toute tentative de telle "redéfinition" entraînera un comportement incorrect ou inattendu, ou ne fonctionnera tout simplement pas.

Peut-on utiliser valueOf ou toString pour influencer indirectement les opérateurs ?

Dans certains cas, on peut utiliser valueOf (par exemple, pour une conversion courte en nombre), mais uniquement pour les opérateurs qui accèdent à la valeur primitive de l'objet.

class Box { constructor(private v: number) {} valueOf() { return this.v; } }
const a = new Box(10);
console.log(a + 5); // 15 — fonctionne, mais pour des objets complexes, c'est contre-intuitif

Mais pour des structures complexes et des opérateurs logiques, il est préférable d'utiliser des méthodes explicites.

Y a-t-il des plans pour ajouter la surcharge d'opérateurs dans TypeScript ou ECMAScript ?

Actuellement, il n'y a pas de plans confirmés : en principe, la surcharge d'opérateurs contredit la conception de JS, car elle pourrait modifier substantiellement le comportement des objets standards et conduire à une instabilité du code.

Erreurs typiques et anti-modèles

• Tentative de redéfinir le comportement standard des opérateurs via valueOf/toString pour des structures complexes
• Utilisation de méthodes avec des noms vagues (par exemple, op, act au lieu de add, equals)
• Typage insuffisant ou signature incorrecte des méthodes personnalisées

Exemple de la vie réelle

Cas négatif

Un développeur crée une classe Matrix, où il implémente valueOf/toString pour l'insertion dans des expressions mathématiques. Lors de l'addition avec des nombres ou des chaînes, des résultats imprévisibles se produisent, ce qui rend le typage strict impossible.

Avantages :

• La syntaxe des opérations est plus concise

Inconvénients :

• Perte de la sécurité typée et de la clarté
• Comportement ambigu lors de l'utilisation avec d'autres objets

Cas positif

La classe Vector implémente des méthodes add, multiply, equals avec un typage clair des paramètres d'entrée et de sortie. Les clients de la classe utilisent explicitement les méthodes correspondantes, la sémantique est préservée, et un typage strict est assuré.

Avantages :

• Comportement prévisible
• Facilité d'extension
• Prise en charge du typage strict

Inconvénients :

• La syntaxe est moins "native" par rapport aux opérateurs
• La réécriture pour un syntaxe arithmétique familière n'est pas prise en charge