Polimorfizm w Javie: jeden interfejs, wiele form

Jedna referencja, wiele typów

Polimorfizm to nagroda za dziedziczenie i interfejsy. Oznacza, że jedna zmienna zadeklarowana z typem nadrzędnym (albo interfejsem) może przechowywać obiekt dowolnego podtypu, a gdy wywołujesz na niej metodę, Java uruchamia wersję należącą do rzeczywistej klasy obiektu, a nie wersję wynikającą z zadeklarowanego typu zmiennej.

Przygotowanie do tego widać już na stronie o dziedziczeniu: podklasa nadpisuje metodę rodzica. Polimorfizm sprawia, że takie nadpisanie ma sens: pozwala pisać kod dla typu ogólnego i zostawić każdemu konkretnemu obiektowi jego własne zachowanie.

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();   // referencja typu nadrzędnego przechowuje obiekt podklasy
        Animal b = new Cat();

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

Zarówno a, jak i b są zadeklarowane jako Animal, a mimo to każdy wypisuje swój własny dźwięk. Ten wybór następuje w czasie działania, na podstawie rzeczywistego obiektu.

Dynamiczne wiązanie metod

Mechanizm, który za tym stoi, to dynamiczne wiązanie metod (dynamic method dispatch): dla nadpisanej metody instancji JVM sprawdza klasę obiektu w czasie działania, żeby zdecydować, którą implementację wywołać. Kompilator sprawdza tylko, czy metoda istnieje w zadeklarowanym typie; faktyczny wybór jest odkładany do chwili uruchomienia programu.

Dzięki temu jedna pętla obsługuje całą mieszankę typów, nigdy nie pytając, czym jest każdy z nich:

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();   // każde wywołanie trafia do rzeczywistej podklasy
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

Pętla zna tylko Shape. Dodaj później Triangle extends Shape, a ten kod dalej działa bez zmian i właśnie o to chodzi. Kod zależy od abstrakcji, a nie od konkretnej listy typów.

Upcasting i downcasting

Zapisanie Dog w zmiennej Animal to upcasting, czyli przejście w górę hierarchii do ogólniejszego typu. Jest zawsze bezpieczny i Java wykonuje go niejawnie, bo każdy Dog jest Animal.

Ruch w drugą stronę to downcasting: bierzesz referencję typu nadrzędnego i traktujesz ją jako konkretny podtyp. To forma rzutowania typów między typami referencyjnymi i jest poprawna tylko wtedy, gdy obiekt naprawdę jest tym podtypem. Dlatego rzutowanie trzeba zapisać jawnie, a jeśli się pomylisz, grozi ci ClassCastException:

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: niejawny, bezpieczny

        Dog d = (Dog) a;        // downcast: jawny, poprawny, bo a naprawdę jest Dog
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // kompiluje się, ale rzuca ClassCastException w czasie działania
        wrong.fetch();
    }
}

Ostatnie rzutowanie kompiluje się bez problemu, bo kompilator nie potrafi udowodnić, że jest błędne, ale wysypuje się w czasie działania, bo Cat nie jest Dog. Nigdy nie rób downcastingu na wiarę.

Zabezpieczaj downcasting przez instanceof

Przed downcastingiem sprawdź rzeczywisty typ przez instanceof. Nowoczesna Java pozwala od razu związać wynik w tym samym wyrażeniu (dopasowanie wzorca dla instanceof), więc osobne rzutowanie nie jest potrzebne:

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) {     // sprawdza typ I wiąże dog
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof zwraca false dla null, więc to sprawdzenie chroni też przed NullPointerException. Mimo to, jeśli piszesz długie łańcuchy instanceof, często jest to znak, że zachowanie powinno znaleźć się wewnątrz klas jako nadpisana metoda. Niech rozgałęzianie wykona za ciebie polimorfizm.

Nadpisywanie a przeciążanie

Te dwa pojęcia brzmią podobnie, ale nie mają ze sobą związku, a ich mylenie to klasyczne źródło nieporozumień.

Nadpisywanie (overriding) to podklasa zastępująca metodę rodzica metodą o identycznej sygnaturze. Jest rozstrzygane w czasie działania według typu obiektu; to polimorfizm, którego używaliśmy do tej pory.

Przeciążanie (overloading) to kilka metod o tej samej nazwie, ale różnych listach parametrów w jednej klasie. Jest rozstrzygane w czasie kompilacji według typów argumentów, bez żadnego wiązania w czasie działania:

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

Kompilator wybiera pasujące describe wyłącznie na podstawie statycznego typu argumentu. Nie ma tu obiektu rodzica ani potomka, więc to nie jest polimorfizm w czasie działania, a jedynie ponowne użycie nazwy metody.

Częsta pułapka: pola nie są polimorficzne

W czasie działania wiązane są tylko metody instancji. Pola i metody statyczne są rozstrzygane według zadeklarowanego typu, na czym potyka się wiele osób:

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

class Child extends Parent {
    String label = "child";          // przesłania, nie nadpisuje
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent: pole używa zadeklarowanego typu
        System.out.println(p.name());   // Child: metoda używa typu z czasu działania
    }
}

p.name() uruchamia wersję z Child (polimorfizm), ale p.label odczytuje pole z Parent, bo pola są przesłaniane, a nie nadpisywane. Rozwiązanie jest proste: trzymaj pola jako private i udostępniaj je tylko przez metody, żeby zawsze wygrywało wywołanie polimorficzne.

Dalej: modyfikatory dostępu

Polimorfizm działa czysto tylko wtedy, gdy podklasy widzą i mogą nadpisać właściwe składowe, a reszta kodu nie może sięgnąć do środka i złamać niezmienników. Tę równowagę kontrolują public, protected, private i dostęp pakietowy, czyli modyfikatory dostępu, o których jest następna strona.