Method Overloading ב-Java: אותו שם, פרמטרים שונים

שם אחד, כמה גרסאות

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

זו הסיבה ש-System.out.println מדפיסה בשמחה int, String, boolean או double: אין println אחת, יש הרבה גרסאות מועמסות שחולקות את השם. כותבים את הקריאה שמתכוונים אליה, והמהדר מתאים אותה לגרסה שמתאימה.

public class Main {
    static int square(int n) {
        return n * n;
    }

    static double square(double n) {
        return n * n;
    }

    public static void main(String[] args) {
        System.out.println(square(5));      // קורא לגרסת int  -> 25
        System.out.println(square(2.5));    // קורא לגרסת double -> 6.25
    }
}

שתי המתודות נקראות square, אבל אחת מקבלת int והשנייה double. הליטרל 5 הוא int, ולכן הגרסה הראשונה רצה; 2.5 הוא double, ולכן השנייה רצה.

מה נחשב גרסה מועמסת שונה

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

• מספר פרמטרים שונה,
• טיפוסי פרמטרים שונים, או
• סדר טיפוסים שונה.

public class Main {
    static String join(String a, String b) {
        return a + b;
    }

    static String join(String a, String b, String c) {   // מספר שונה
        return a + b + c;
    }

    static String join(String a, int times) {             // טיפוסים שונים
        return a.repeat(times);
    }

    public static void main(String[] args) {
        System.out.println(join("a", "b"));
        System.out.println(join("a", "b", "c"));
        System.out.println(join("hi", 3));
    }
}

לכל קריאה יש רשימת ארגומנטים שמתאימה בדיוק לאחת משלוש מתודות ה-join, כך שאין בלבול.

טיפוס ההחזרה לא נחשב

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

// לא עובר קומפילציה: אותו שם, אותם פרמטרים, רק טיפוס ההחזרה שונה
static int   value() { return 1; }
static double value() { return 1.0; }   // error: value() כבר מוגדרת

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

איך Java בוחרת גרסה מועמסת

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

public class Main {
    static void show(int n)    { System.out.println("int: " + n); }
    static void show(long n)   { System.out.println("long: " + n); }
    static void show(double n) { System.out.println("double: " + n); }

    public static void main(String[] args) {
        show(7);     // התאמה מדויקת -> int
        show(7L);    // התאמה מדויקת -> long
        show(7.0);   // התאמה מדויקת -> double
    }
}

show(7) מתאימה בדיוק ל-int, למרות ש-long ו-double יכולים גם הם להכיל 7 אחרי הרחבה. רק אם הגרסה המדויקת הייתה נמחקת, המהדר היה מרחיב את int ל-long, ואז ל-double. הבחירה הזו מתקבלת כולה בזמן קומפילציה, לפי הטיפוסים המוצהרים של הארגומנטים.

היזהרו מקריאות עמומות

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

static void handle(String s) { }
static void handle(StringBuilder b) { }

handle(null);   // error: ההפניה ל-handle עמומה

שתי הגרסאות מקבלות null, ואף אחת אינה ספציפית יותר, ולכן הקריאה לא עוברת קומפילציה. מתקנים את זה בכך שהופכים את הטיפוס למפורש עם המרה, handle((String) null), או בתכנון מחדש כך שהגרסאות לא יתנגשו. אותה זהירות נדרשת כשמערבבים autoboxing והרחבה; שמרו על קבוצות גרסאות פשוטות מספיק כדי שלכל קריאה יהיה מנצח אחד ברור.

העמסת בנאים

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

public class Main {
    static class Point {
        int x, y;

        Point() {
            this(0, 0);          // מעביר לבנאי עם שני הארגומנטים
        }

        Point(int x, int y) {
            this.x = x;
            this.y = y;
        }

        public String toString() {
            return "(" + x + ", " + y + ")";
        }
    }

    public static void main(String[] args) {
        System.out.println(new Point());      // (0, 0)
        System.out.println(new Point(3, 4));  // (3, 4)
    }
}

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

Overloading מול Overriding

השניים נשמעים דומים, אבל אין ביניהם קשר:

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

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

הבא: Varargs

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