Le polymorphisme en Java : une interface, plusieurs formes

Une référence, plusieurs types

Le polymorphisme est la récompense de l'héritage et des interfaces. Il signifie qu'une seule variable typée comme un parent (ou une interface) peut contenir un objet de n'importe quel sous-type, et lorsque vous appelez une méthode dessus, Java exécute la version appartenant à la classe réelle de l'objet - et non la version impliquée par le type déclaré de la variable.

Vous avez déjà vu le principe sur la page sur l'héritage : une sous-classe redéfinit une méthode de son parent. Le polymorphisme est ce qui rend cette redéfinition utile - il vous permet d'écrire du code contre le type général et de laisser chaque objet concret se comporter à sa manière.

class Animal {
    String speak() { return "..."; }
}

class Dog extends Animal {
    String speak() { return "Woof"; }
}

class Cat extends Animal {
    String speak() { return "Meow"; }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // une référence parent contenant un objet enfant
        Animal b = new Cat();

        System.out.println(a.speak());   // Woof
        System.out.println(b.speak());   // Meow
    }
}

a et b sont tous deux déclarés comme Animal, pourtant chacun affiche son propre son. Ce choix se fait à l'exécution en fonction de l'objet réel.

La répartition dynamique des méthodes

Le mécanisme sous-jacent est la répartition dynamique des méthodes (dynamic method dispatch) : pour une méthode d'instance redéfinie, la JVM examine la classe à l'exécution de l'objet pour décider quelle implémentation appeler. Le compilateur vérifie seulement que la méthode existe sur le type déclaré ; la sélection réelle est différée jusqu'à l'exécution du programme.

C'est ce qui permet à une seule boucle de gérer tout un mélange de types sans jamais demander ce qu'est chacun d'eux :

import java.util.List;

class Shape {
    double area() { return 0; }
}

class Circle extends Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    double area() { return Math.PI * r * r; }
}

class Square extends Shape {
    private final double side;
    Square(double side) { this.side = side; }
    double area() { return side * side; }
}

public class Main {
    public static void main(String[] args) {
        List<Shape> shapes = List.of(new Circle(1), new Square(2), new Circle(3));

        double total = 0;
        for (Shape shape : shapes) {
            total += shape.area();   // chaque appel est dirigé vers la vraie sous-classe
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

La boucle ne connaît que Shape. Ajoutez un Triangle extends Shape plus tard et ce code continue de fonctionner sans modification - c'est tout l'intérêt. Le code dépend de l'abstraction, pas de la liste concrète des types.

Upcasting et downcasting

Stocker un Dog dans une variable Animal est de l'upcasting - remonter la hiérarchie vers un type plus général. C'est toujours sûr et Java le fait implicitement, car tout Dog est un Animal.

Aller dans l'autre sens est du downcasting - prendre une référence parent et la traiter comme un sous-type spécifique. Cela n'est valide que si l'objet est réellement de ce sous-type, vous devez donc écrire le cast explicitement, et vous risquez une ClassCastException si vous vous trompez :

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal { }

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // upcast - implicite, sûr

        Dog d = (Dog) a;        // downcast - explicite, valide car a est réellement un Dog
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // compile, mais lève une ClassCastException à l'exécution
        wrong.fetch();
    }
}

Le dernier cast compile sans problème - le compilateur ne peut pas prouver qu'il est faux - mais il explose à l'exécution car un Cat n'est pas un Dog. Ne faites jamais de downcast à l'aveugle.

Protéger les downcasts avec instanceof

Avant de faire du downcasting, vérifiez le type réel avec instanceof. Le Java moderne vous permet de lier le résultat dans la même expression (filtrage par motif pour instanceof), ce qui vous évite le cast séparé :

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal {
    void scratch() { System.out.println("scratching"); }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Dog(), new Cat(), new Dog() };

        for (Animal animal : animals) {
            if (animal instanceof Dog dog) {     // vérifie le type ET lie dog
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof renvoie false pour null, donc la vérification vous protège aussi d'une NullPointerException. Cela dit, si vous vous surprenez à écrire de longues chaînes de instanceof, c'est souvent le signe que le comportement devrait se trouver à l'intérieur des classes sous forme de méthode redéfinie - laissez le polymorphisme gérer le branchement à votre place.

Overriding vs overloading

Ces deux termes se ressemblent mais n'ont aucun rapport, et les confondre est une source classique de confusion.

L'overriding (redéfinition) est une sous-classe qui remplace une méthode du parent ayant la signature identique. Il est résolu à l'exécution selon le type de l'objet - c'est le polymorphisme que nous utilisons.

L'overloading (surcharge) est une même classe ayant plusieurs méthodes du même nom mais avec des listes de paramètres différentes. Il est résolu à la compilation selon les types des arguments, sans aucune répartition à l'exécution :

public class Main {
    static String describe(int x)    { return "int: " + x; }
    static String describe(double x) { return "double: " + x; }
    static String describe(String x) { return "String: " + x; }

    public static void main(String[] args) {
        System.out.println(describe(5));      // int: 5
        System.out.println(describe(5.0));    // double: 5.0
        System.out.println(describe("five")); // String: five
    }
}

Le compilateur choisit le describe correspondant uniquement à partir du type statique de l'argument. Aucun objet parent/enfant n'est impliqué, donc ce n'est pas du polymorphisme à l'exécution - cela réutilise simplement un nom de méthode.

Un piège courant : les champs ne sont pas polymorphes

Seules les méthodes d'instance sont réparties à l'exécution. Les champs et les méthodes statiques sont résolus selon le type déclaré, ce qui en piège beaucoup :

class Parent {
    String label = "parent";
    String name() { return "Parent"; }
}

class Child extends Parent {
    String label = "child";          // masque, ne redéfinit pas
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent  - le champ utilise le type déclaré
        System.out.println(p.name());   // Child   - la méthode utilise le type à l'exécution
    }
}

p.name() exécute la version de Child (polymorphisme), mais p.label lit le champ de Parent, car les champs sont masqués, pas redéfinis. La solution est simple : gardez les champs private et accédez-y uniquement via des méthodes, pour que l'appel polymorphe l'emporte toujours.

Suite : les modificateurs d'accès

Le polymorphisme ne fonctionne proprement que lorsque les sous-classes peuvent voir et redéfinir les bons membres tandis que le reste de votre code ne peut pas s'y immiscer et briser les invariants. Cet équilibre est contrôlé par les accès public, protected, private et de paquet - les modificateurs d'accès, juste après.