Polymorphisme en Java - héritage, interfaces et erreurs à éviter

Quand une même instruction doit fonctionner avec plusieurs types d’objets, le polymorphisme en Java devient rapidement indispensable. Cette notion permet de manipuler des objets enfants à travers une référence de leur classe parent, tout en exécutant automatiquement le comportement adapté. Je vais montrer son fonctionnement avec des exemples concrets, expliquer la différence entre redéfinition et surcharge, puis présenter les erreurs qui rendent ce mécanisme difficile à maîtriser.

Comprendre le polymorphisme avec une situation simple

Le principe est plus facile à saisir avec une image mentale. Une variable de type Animal peut référencer un Chien ou un Chat, car ces deux classes sont des formes particulières d’animal. Pourtant, lorsqu’on appelle une méthode redéfinie comme crier(), Java exécute le comportement du véritable objet créé.

class Animal {
    void crier() {
        System.out.println("L'animal émet un son");
    }
}

class Chien extends Animal {
    @Override
    void crier() {
        System.out.println("Le chien aboie");
    }
}

class Chat extends Animal {
    @Override
    void crier() {
        System.out.println("Le chat miaule");
    }
}

Animal premier = new Chien();
Animal second = new Chat();

premier.crier(); // Le chien aboie
second.crier();  // Le chat miaule

Les deux variables ont le type déclaré Animal, mais leur type réel est différent. C’est cette distinction entre type de référence et type réel de l’objet qui explique le résultat. Je trouve ce point essentiel, car beaucoup d’erreurs viennent d’une confusion entre ce que la variable autorise à appeler et ce que l’objet sait réellement faire.

La référence parent donne accès aux méthodes connues par la classe parent. En revanche, si une méthode est redéfinie dans la classe enfant, Java utilise l’implémentation de l’objet réel. On parle alors de liaison dynamique ou de sélection de méthode à l’exécution.

Comment Java choisit la bonne méthode

Le polymorphisme repose principalement sur l’héritage, la redéfinition et la liaison dynamique. Une classe enfant reprend le contrat de sa classe parent, puis peut fournir une implémentation plus spécialisée. Le code qui utilise le type parent n’a pas besoin de connaître chaque classe enfant à l’avance.

Voici un exemple plus proche d’une application réelle avec des moyens de paiement :

abstract class Paiement {
    abstract void effectuer(double montant);
}

class CarteBancaire extends Paiement {
    @Override
    void effectuer(double montant) {
        System.out.println("Paiement par carte : " + montant + " €");
    }
}

class Virement extends Paiement {
    @Override
    void effectuer(double montant) {
        System.out.println("Virement bancaire : " + montant + " €");
    }
}

void traiterPaiement(Paiement paiement) {
    paiement.effectuer(49.90);
}

traiterPaiement(new CarteBancaire());
traiterPaiement(new Virement());

La méthode traiterPaiement() ne dépend d’aucune classe concrète. Elle accepte un objet de type Paiement et délègue le travail à son implémentation réelle. Pour moi, c’est là que le polymorphisme prend toute sa valeur en production, car on peut ajouter PayPal ou un autre moyen de paiement sans réécrire la logique principale.

Le compilateur vérifie d’abord que la méthode existe dans le type déclaré. Ensuite, au moment de l’exécution, la JVM sélectionne la version redéfinie correspondant à l’objet. Si la référence est de type Paiement, elle ne permet donc pas d’appeler directement une méthode uniquement déclarée dans CarteBancaire.

Redéfinition et surcharge ne jouent pas le même rôle

Ces deux notions sont souvent mélangées alors qu’elles répondent à des problèmes différents. La redéfinition concerne une classe enfant qui remplace le comportement hérité. La surcharge consiste à déclarer plusieurs méthodes portant le même nom, mais avec des paramètres différents.

La surcharge peut prendre cette forme :

class Calculatrice {
    int additionner(int a, int b) {
        return a + b;
    }

    double additionner(double a, double b) {
        return a + b;
    }
}

Java choisit ici la méthode en fonction des types et du nombre d’arguments disponibles au moment de la compilation. Avec la redéfinition, le choix dépend du type réel de l’objet. Cette différence paraît théorique, mais elle explique pourquoi modifier le type d’une variable peut changer les méthodes accessibles, sans forcément changer la méthode exécutée.

J’ajoute presque toujours l’annotation @Override lors d’une redéfinition. Elle n’est pas obligatoire dans tous les cas, mais elle permet au compilateur de détecter une faute de signature, une faute de frappe ou une méthode qui ne remplace finalement rien.

Les interfaces rendent le code plus adaptable

Le polymorphisme ne dépend pas uniquement des classes parentes. En Java, une interface définit surtout un contrat de comportement que plusieurs classes peuvent respecter, même si elles ne partagent pas la même classe parent.

interface Exportateur {
    void exporter(String contenu);
}

class ExportPdf implements Exportateur {
    @Override
    public void exporter(String contenu) {
        System.out.println("Export au format PDF");
    }
}

class ExportCsv implements Exportateur {
    @Override
    public void exporter(String contenu) {
        System.out.println("Export au format CSV");
    }
}

void lancerExport(Exportateur exportateur) {
    exportateur.exporter("Données clients");
}

La méthode lancerExport() travaille avec l’interface et non avec une classe précise. Cette organisation facilite les tests, car je peux fournir une implémentation fictive, et elle réduit le couplage entre les composants. En pratique, une interface est souvent préférable lorsque l’on veut exprimer ce qu’un objet sait faire plutôt que la manière dont il a été construit.

Java autorise aussi une classe à implémenter plusieurs interfaces. Cela permet de combiner plusieurs contrats sans recourir à l’héritage multiple de classes, qui n’est pas permis. Si deux interfaces fournissent des méthodes par défaut incompatibles, la classe doit résoudre explicitement le conflit, faute de quoi le code ne compile pas.

Cette approche est très présente dans les bibliothèques Java. Une collection peut être manipulée à travers une interface comme List, tandis que l’implémentation concrète peut être une ArrayList ou une LinkedList. Le programme dépend alors du comportement attendu, pas du détail de stockage choisi.

Les limites et les erreurs qui reviennent souvent

Le polymorphisme simplifie l’évolution d’un programme, mais il ne rend pas toutes les opérations possibles. Une référence de type parent ne donne accès qu’aux membres visibles depuis ce type, même si l’objet réel appartient à une classe enfant plus riche.

class Animal {
    void manger() {
        System.out.println("L'animal mange");
    }
}

class Chien extends Animal {
    void courir() {
        System.out.println("Le chien court");
    }
}

Animal animal = new Chien();
animal.manger();

// Impossible directement : la référence Animal
// ne connaît pas courir()
animal.courir();

Dans ce cas, une conversion explicite peut fonctionner, mais elle doit rester justifiée :

if (animal instanceof Chien chien) {
    chien.courir();
}

Je déconseille de multiplier les tests avec instanceof. Quelques vérifications peuvent être normales, mais une longue chaîne de conditions révèle souvent que le modèle devrait utiliser une méthode polymorphe supplémentaire ou une interface mieux définie. Le polymorphisme doit déplacer la décision vers l’objet concerné, pas remplacer un grand if par une série de conversions.

Il faut aussi distinguer les méthodes d’instance des champs et des méthodes statiques. Une méthode d’instance redéfinie est choisie selon l’objet réel, tandis qu’un champ est lié au type de la référence. Les méthodes static sont masquées et non redéfinies au sens polymorphique classique. Les méthodes private, elles, ne sont pas héritées de manière exploitable par une sous-classe.

Enfin, une redéfinition doit respecter les règles de compatibilité de Java. La signature doit correspondre, la visibilité ne peut pas être réduite et le type de retour doit rester compatible. Une méthode abstraite impose une implémentation aux classes concrètes, ce qui garantit que le contrat sera bien respecté.

Quand utiliser ce mécanisme dans un projet

Je recommande le polymorphisme dès qu’un traitement doit accepter plusieurs variantes d’un même concept. Les bons cas d’usage sont les stratégies de calcul, les systèmes de notification, les formats d’export, les moyens de paiement, les connecteurs réseau et les règles métier qui peuvent évoluer.

• Utilisez une classe abstraite lorsque plusieurs classes partagent un état ou du code commun.
• Préférez une interface lorsque vous voulez définir un comportement indépendant de la hiérarchie de classes.
• Gardez les méthodes utilisées par le code général au niveau du contrat commun.
• Ajoutez @Override pour sécuriser chaque redéfinition.
• Évitez les hiérarchies très profondes, qui rendent le comportement difficile à suivre.

Le gain ne se mesure pas seulement au nombre de lignes économisées. Un code polymorphe bien conçu permet surtout d’ajouter une nouvelle implémentation avec moins de risques de régression. En contrepartie, il faut accepter un peu plus d’abstraction et prendre le temps de nommer clairement les contrats.

Un autre piège consiste à créer une classe parent uniquement pour réutiliser quelques lignes de code. L’héritage exprime une relation de type « est un », pas simplement une envie de partager une méthode. Si cette relation n’est pas naturelle, la composition est souvent plus claire et plus souple.

Le bon réflexe pour retenir le polymorphisme

Pour vérifier votre compréhension, partez toujours de trois questions. Quel est le type déclaré de la référence ? Quel est le type réel de l’objet ? La méthode appelée est-elle redéfinie, surchargée, statique ou privée ?

Si vous répondez correctement à ces trois questions, vous pouvez généralement prévoir le comportement du programme sans l’exécuter. Le réflexe le plus utile consiste à programmer contre une interface ou une abstraction stable, puis à laisser chaque classe concrète fournir son comportement.

Le polymorphisme en Java n’est donc pas une astuce syntaxique isolée. C’est une manière de concevoir des composants qui dialoguent par contrats, restent remplaçables et évoluent sans fragiliser toute l’application.