Réponse.

Java ne prend pas en charge la surcharge des opérateurs de la manière dont cela est réalisé, par exemple, en C++. Historiquement, cette restriction a été mise en place pour faciliter la lisibilité du code et réduire l'ambiguïté : Bjarne Stroustrup (le créateur de C++) et James Gosling (le créateur de Java) ont discuté de cette question, et en Java, il a été décidé de ne pas permettre aux développeurs de définir leur propre comportement des opérateurs pour leurs classes.

Le problème de la surcharge des opérateurs est que la liberté excessive dans la définition de l'arithmétique et de la logique pour les classes personnalisées peut entraîner des bogues difficilement traçables et une détérioration de la lisibilité du code, surtout dans de grandes équipes.

La solution consiste à interdire la surcharge des opérateurs par l'utilisateur. Néanmoins, Java prend en charge la surcharge des méthodes à l'intérieur de ses classes, et le comportement des opérateurs peut être imité par des méthodes explicitement définies (par exemple, .add(), .equals(), .compareTo(), etc.).

Exemple de code :

public class Vector2D {
    private final int x, y;
    public Vector2D(int x, int y) {
        this.x = x; this.y = y;
    }
    public Vector2D add(Vector2D other) {
        return new Vector2D(this.x + other.x, this.y + other.y);
    }
}

Vector2D v1 = new Vector2D(2, 3);
Vector2D v2 = new Vector2D(1, 4);
Vector2D sum = v1.add(v2); // au lieu de v1 + v2

Caractéristiques clés :

Transmission explicite de la sémantique des opérations via des méthodes, et non via la surcharge d'opérateur
Le comportement des opérateurs standard (par exemple, "+", "-") ne peut pas être changé pour les classes personnalisées
Une exception concerne la surcharge des opérations pour les chaînes : l'opérateur "+" appelle concat()

Questions pièges.

Peut-on surcharger l'opérateur "+" en Java pour sa propre classe afin d'additionner des objets ?

Réponse : Non, Java ne prend pas en charge la surcharge personnalisée des opérateurs arithmétiques pour les classes créées. L'exception n'est faite que pour les chaînes : l'opérateur "+" appelle la concaténation via StringBuilder.

Si on définit la méthode equals(), l'opérateur "==" fonctionnera-t-il comme une comparaison de valeurs ?

Réponse : Non, l'opérateur "==" compare les références des objets, et non leur contenu. Pour une comparaison correcte des valeurs, on utilise equals() redéfini.

String a = new String("hello");
String b = new String("hello");
System.out.println(a == b);    // false
System.out.println(a.equals(b)); // true

Y a-t-il des exceptions où l'opérateur standard se comporte différemment pour des classes non standard ?

Réponse : Un comportement "particulier" en Java n'est mis en œuvre que pour String avec l'opérateur "+" et pour les types primitifs (promotion automatique et unboxing). Pour les autres classes, les opérateurs fonctionnent normalement (c'est-à-dire ne sont pas surchargés).

erreurs typiques et anti-patrons

Tenter de surcharger les opérateurs lors de la conception de sa propre classe (par exemple, s'attendre à ce que "==" compare des valeurs)
Utilisation de "==" au lieu de .equals() pour des chaînes et d'autres objets
Imitations de surcharge trop complexes via des méthodes statiques, nuisant à la lisibilité

Exemple de la vie réelle

Cas négatif

Un jeune développeur a écrit une classe Money et a commencé à comparer deux objets via "==", pensant qu'ils seraient comparés par valeurs. Cela a entraîné des erreurs lors de la vérification de l'égalité, qui ne se sont manifestées qu'en production.

Avantages :

Dans de courts programmes, l'erreur peut parfois rester inaperçue jusqu'aux tests.

Inconvénients :

Sémantique incorrecte des opérations de comparaison, difficulté de débogage
Temps perdu à expliquer au sein de l'équipe

Cas positif

Dans le projet, une classe Vector a été écrite, toutes les opérations arithmétiques sont implémentées de manière explicite, l'opérateur == n'est pas utilisé pour les objets, et la documentation décrit la sémantique de fonctionnement des méthodes.