ProgrammationDéveloppeur Java

Qu'est-ce que la surcharge (overloading) de méthodes en Java, comment elle est mise en œuvre et quelles sont les subtilités à prendre en compte lors de son utilisation ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse

La surcharge de méthodes (method overloading) est la possibilité de créer plusieurs méthodes avec le même nom mais des paramètres différents (type, ordre, quantité) dans une même classe. Cette approche permet de regrouper logiquement des opérations similaires et d'améliorer la lisibilité du code.

public class MathUtil { public int sum(int a, int b) { return a + b; } public double sum(double a, double b) { return a + b; } public int sum(int a, int b, int c) { return a + b + c; } }

Subtilités :

  • Java distingue les méthodes par leur signature (nom + liste de paramètres); le type de retour n'a pas d'importance pour la surcharge.
  • Lors de la surcharge des méthodes avec des types primitifs, des conversions implicites (widening) peuvent se produire, ce qui peut entraîner des ambiguïtés dans l'appel.
  • L'utilisation de varargs dans les méthodes surchargées nécessite de la prudence pour ne pas obtenir des résultats inattendus lors de l'appel de la méthode souhaitée.

Question piège

Question : Peut-on surcharger des méthodes uniquement sur la base du type de retour (sans changer les paramètres) ?

Réponse : Non. La surcharge n'est possible que s'il y a une différence dans la liste des paramètres. Un simple changement de type de retour provoquera une erreur de compilation.

void foo(int a) {} int foo(int a) { return 1; } // Erreur ! Le type de retour n'est pas pris en compte lors de la surcharge.

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


Histoire

Dans un projet, un développeur a créé deux méthodes :

public void process(int x, double y) {...} public void process(double x, int y) {...}

Lors de l'appel process(5, 10), le compilateur ne peut pas choisir la bonne version, ce qui entraînait une erreur d'ambiguïté lors de l'appel. Cela ralentissait la livraison du module.


Histoire

Dans une application, des méthodes avec surcharge basées sur varargs et tableaux :

public void log(String... messages) {...} public void log(String[] messages) {...}

La transmission d'un tableau String[] data n’appelait pas toujours la surcharge attendue, ce qui faisait que certaines données étaient loguées incorrectement — certaines informations étaient perdues ! La différence entre un tableau et varargs s'est révélée critique.


Histoire

Un développeur a surchargé les méthodes d'une classe sans prendre en compte l'autoboxing des types :

public void save(Integer i) {...} public void save(int i) {...}

Lors de l'appel save(null), un NullPointerException s'est produit du côté de l'appel avec le type primitif int, car Java choisit le type le plus spécifique (int), mais il est impossible de convertir null en primitif !