Polimorfismo in Java: un'interfaccia, tante forme

Un riferimento, tanti tipi

Il polimorfismo è il frutto dell'ereditarietà e delle interfacce. Significa che una sola variabile con il tipo di un padre (o di un'interfaccia) può contenere un oggetto di qualsiasi sottotipo, e quando chiami un suo metodo Java esegue la versione della classe reale dell'oggetto, non quella suggerita dal tipo dichiarato della variabile.

Hai già visto la base nella pagina sull'ereditarietà: una sottoclasse sovrascrive un metodo del padre. Il polimorfismo è ciò che rende utile quell'override: ti permette di scrivere codice per il tipo generale e di lasciare che ogni oggetto concreto si comporti a modo suo.

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();   // un riferimento padre che contiene un oggetto figlio
        Animal b = new Cat();

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

Sia a sia b sono dichiarati come Animal, eppure ciascuno stampa il proprio verso. La scelta avviene a runtime in base all'oggetto reale.

Dispatch dinamico dei metodi

Il meccanismo dietro a tutto questo è il dispatch dinamico dei metodi: per un metodo di istanza sovrascritto, la JVM guarda la classe dell'oggetto a runtime per decidere quale implementazione chiamare. Il compilatore controlla solo che il metodo esista nel tipo dichiarato; la scelta vera e propria viene rimandata a quando il programma è in esecuzione.

È questo che permette a un solo ciclo di gestire un insieme misto di tipi senza mai chiedere che cosa sia ciascuno:

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();   // ogni chiamata va alla sottoclasse reale
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

Il ciclo conosce solo Shape. Se più avanti aggiungi un Triangle extends Shape, questo codice continua a funzionare senza modifiche: è proprio questo il punto. Il codice dipende dall'astrazione, non dall'elenco concreto dei tipi.

Upcasting e downcasting

Salvare un Dog in una variabile Animal è un upcasting: si sale nella gerarchia verso un tipo più generale. È sempre sicuro e Java lo fa in modo implicito, perché ogni Dog è un Animal.

Andare nella direzione opposta è un downcasting: prendi un riferimento al padre e lo tratti come un sottotipo specifico. È una forma di type casting tra tipi riferimento, ed è valida solo se l'oggetto è davvero di quel sottotipo, quindi devi scrivere il cast in modo esplicito e rischi una ClassCastException se sbagli:

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: implicito, sicuro

        Dog d = (Dog) a;        // downcast: esplicito, valido perché a è davvero un Dog
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // compila, ma lancia ClassCastException a runtime
        wrong.fetch();
    }
}

L'ultimo cast compila senza problemi, perché il compilatore non può dimostrare che è sbagliato, ma esplode quando viene eseguito, perché un Cat non è un Dog. Non fare mai un downcast sulla fiducia.

Proteggere i downcast con instanceof

Prima di un downcast, controlla il tipo reale con instanceof. Il Java moderno ti permette di legare il risultato nella stessa espressione (pattern matching per instanceof), così eviti il cast separato:

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) {     // controlla il tipo E crea dog
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof restituisce false per null, quindi il controllo ti protegge anche da una NullPointerException. Detto questo, se ti ritrovi a scrivere lunghe catene di instanceof, spesso è segno che quel comportamento appartiene alle classi stesse come metodo sovrascritto: lascia che sia il polimorfismo a scegliere il ramo al posto tuo.

Overriding e overloading

Questi due termini si somigliano ma non hanno niente in comune, e confonderli è una fonte classica di dubbi.

L'overriding è una sottoclasse che sostituisce un metodo del padre con la stessa identica firma. Si risolve a runtime in base al tipo dell'oggetto: è il polimorfismo che abbiamo usato finora.

L'overloading è una classe che ha più metodi con lo stesso nome ma liste di parametri diverse. Si risolve in fase di compilazione in base ai tipi degli argomenti, senza alcun dispatch a runtime:

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
    }
}

Il compilatore sceglie il describe corrispondente basandosi solo sul tipo statico dell'argomento. Non ci sono oggetti padre e figlio in gioco, quindi questo non è polimorfismo a runtime: è solo il riutilizzo di un nome di metodo.

Una trappola comune: i campi non sono polimorfici

Solo i metodi di istanza vengono scelti a runtime. I campi e i metodi statici si risolvono in base al tipo dichiarato, e questo confonde molte persone:

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

class Child extends Parent {
    String label = "child";          // nasconde, non sovrascrive
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent: il campo usa il tipo dichiarato
        System.out.println(p.name());   // Child: il metodo usa il tipo a runtime
    }
}

p.name() esegue la versione di Child (polimorfismo), ma p.label legge il campo di Parent, perché i campi vengono nascosti, non sovrascritti. La soluzione è semplice: tieni i campi private e accedi a loro solo tramite metodi, così vince sempre la chiamata polimorfica.

Prossima pagina: modificatori di accesso

Il polimorfismo funziona bene solo quando le sottoclassi possono vedere e sovrascrivere i membri giusti, mentre il resto del codice non può entrare e rompere le invarianti. Questo equilibrio è controllato dagli accessi public, protected, private e package-private: i modificatori di accesso, nella prossima pagina.