פולימורפיזם ב-Java: ממשק אחד, צורות רבות

הפניה אחת, טיפוסים רבים

פולימורפיזם הוא הרווח מירושה וממשקים. הוא אומר שמשתנה יחיד שהטיפוס שלו הוא הורה (או ממשק) יכול להחזיק אובייקט מכל תת-טיפוס, וכשקוראים עליו למתודה, Java מריצה את הגרסה ששייכת למחלקה האמיתית של האובייקט, ולא את הגרסה שמשתמעת מהטיפוס המוצהר של המשתנה.

כבר ראיתם את ההכנה בעמוד על ירושה: תת-מחלקה דורסת מתודה של ההורה שלה. פולימורפיזם הוא מה שהופך את הדריסה לשווה: הוא מאפשר לכתוב קוד מול הטיפוס הכללי ולתת לכל אובייקט קונקרטי להתנהג בדרכו.

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();   // הפניה מטיפוס הורה שמחזיקה אובייקט בן
        Animal b = new Cat();

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

גם a וגם b מוצהרים כ-Animal, ובכל זאת כל אחד מדפיס את הקול שלו. הבחירה הזו קורית בזמן ריצה, לפי האובייקט האמיתי.

Dynamic Method Dispatch

המנגנון שמאחורי זה נקרא dynamic method dispatch: עבור מתודת מופע דרוסה, ה-JVM מסתכלת על המחלקה של האובייקט בזמן ריצה כדי להחליט איזה מימוש להפעיל. המהדר רק בודק שהמתודה קיימת בטיפוס המוצהר; הבחירה בפועל נדחית עד שהתוכנית רצה.

זה מה שמאפשר ללולאה אחת לטפל בתערובת שלמה של טיפוסים בלי לשאול אף פעם מה כל אחד מהם:

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();   // כל קריאה מנותבת לתת-המחלקה האמיתית
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

הלולאה מכירה רק את Shape. הוסיפו בהמשך Triangle extends Shape, והקוד הזה ימשיך לעבוד בלי שינוי: זו כל הנקודה. הקוד תלוי בהפשטה, לא ברשימה הקונקרטית של הטיפוסים.

Upcasting ו-Downcasting

שמירת Dog במשתנה Animal היא upcasting: תנועה למעלה בהיררכיה לטיפוס כללי יותר. זה תמיד בטוח ו-Java עושה את זה במובלע, כי כל Dog הוא Animal.

הכיוון ההפוך הוא downcasting: לקחת הפניה מטיפוס הורה ולהתייחס אליה כתת-טיפוס מסוים. זו צורה של המרת טיפוסים בין טיפוסי הפניה, והיא תקפה רק אם האובייקט באמת מאותו תת-טיפוס, ולכן צריך לכתוב את ההמרה במפורש, ומסתכנים ב-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: מובלע, בטוח

        Dog d = (Dog) a;        // downcast: מפורש, תקף כי a הוא באמת Dog
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // עובר קומפילציה, אבל זורק ClassCastException בזמן ריצה
        wrong.fetch();
    }
}

ההמרה האחרונה עוברת קומפילציה בלי בעיה, כי המהדר לא יכול להוכיח שהיא שגויה, אבל מתפוצצת בזמן ריצה כי Cat הוא לא Dog. לעולם אל תבצעו downcast על סמך אמונה.

הגנה על downcast עם instanceof

לפני downcast, בדקו את הטיפוס האמיתי עם instanceof. Java מודרנית מאפשרת לקשור את התוצאה באותו ביטוי (pattern matching ל-instanceof), כך שמדלגים על ההמרה הנפרדת:

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) {     // בודק את הטיפוס וגם קושר את dog
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof מחזיר false עבור null, כך שהבדיקה מגינה גם מפני NullPointerException. עם זאת, אם אתם מוצאים את עצמכם כותבים שרשראות ארוכות של instanceof, זה לעיתים קרובות סימן שההתנהגות שייכת בתוך המחלקות כמתודה דרוסה: תנו לפולימורפיזם לעשות את ההסתעפות בשבילכם.

Overriding מול Overloading

השניים נשמעים דומים אבל אין ביניהם קשר, וערבוב ביניהם הוא טעות קלאסית.

Overriding (דריסה) הוא תת-מחלקה שמחליפה מתודה של ההורה עם חתימה זהה. הוא מוכרע בזמן ריצה לפי טיפוס האובייקט, וזה הפולימורפיזם שבו השתמשנו עד עכשיו.

Overloading (העמסה) הוא מחלקה אחת עם כמה מתודות באותו שם אבל רשימות פרמטרים שונות. הוא מוכרע בזמן קומפילציה לפי טיפוסי הארגומנטים, בלי שום ניתוב בזמן ריצה:

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

המהדר בוחר את ה-describe המתאים אך ורק לפי הטיפוס הסטטי של הארגומנט. אין כאן אובייקט הורה או בן, ולכן זה לא פולימורפיזם בזמן ריצה: זה רק שימוש חוזר בשם של מתודה.

מלכודת נפוצה: שדות אינם פולימורפיים

רק מתודות מופע מנותבות בזמן ריצה. שדות ומתודות סטטיות מוכרעים לפי הטיפוס המוצהר, וזה מכשיל הרבה אנשים:

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

class Child extends Parent {
    String label = "child";          // מסתיר, לא דורס
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent: השדה משתמש בטיפוס המוצהר
        System.out.println(p.name());   // Child: המתודה משתמשת בטיפוס בזמן ריצה
    }
}

p.name() מריצה את הגרסה של Child (פולימורפיזם), אבל p.label קורא את השדה של Parent, כי שדות מוסתרים ולא נדרסים. התיקון פשוט: שמרו שדות כ-private וגשו אליהם רק דרך מתודות, כך שהקריאה הפולימורפית תמיד מנצחת.

הבא: מגדירי גישה

פולימורפיזם עובד בצורה נקייה רק כשתת-מחלקות יכולות לראות ולדרוס את האיברים הנכונים, בזמן ששאר הקוד לא יכול להיכנס פנימה ולשבור אינווריאנטים. את האיזון הזה קובעים public, protected, private וגישת package-private: מגדירי הגישה (access modifiers), בעמוד הבא.