Java Generics: מחלקות ומתודות עם בטיחות טיפוסים

למה קיימים generics

טיפוס גנרי מאפשר לכתוב קוד פעם אחת ולהשתמש בו מחדש עם טיפוסים רבים, בלי לוותר על בטיחות טיפוסים. במקום לכתוב IntBox, StringBox ו-UserBox נפרדים, כותבים Box<T> אחד, שבו T הוא ממלא מקום שהקורא ממלא.

כבר השתמשתם ב-generics בכל פעם שכתבתם ArrayList<String> או HashMap כמו HashMap<String, Integer>. החלק <...> הוא ארגומנט טיפוס. העמוד הזה מראה איך לכתוב generics משלכם.

החלופה, לשמור הכול כ-Object, זורקת את מידע הטיפוס ומחייבת המרות מכוערות שמזמינות טעויות:

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<Object> raw = new ArrayList<>();
        raw.add("hello");
        raw.add(42);                       // שום דבר לא מונע את הטעות הזו

        String first = (String) raw.get(0); // כל קריאה צריכה המרה
        String oops = (String) raw.get(1);  // מתקמפל, ואז קורס בזמן ריצה
        System.out.println(first + " " + oops);
    }
}

ההמרה בשורה האחרונה זורקת ClassCastException בזמן ריצה: בדיוק סוג ה-exception ש-generics נועדו להפוך לבלתי אפשרי.

מחלקה גנרית

מצהירים על פרמטר טיפוס בסוגריים משולשים אחרי שם המחלקה. לפי המוסכמה זו אות גדולה אחת: T ל-"type", E ל-"element", K/V ל-key/value.

class Box<T> {
    private T value;

    Box(T value) { this.value = value; }

    T get() { return value; }
    void set(T value) { this.value = value; }
}

public class Main {
    public static void main(String[] args) {
        Box<String> name = new Box<>("Coddy");
        Box<Integer> count = new Box<>(3);

        String s = name.get();     // בלי המרה: הקומפיילר יודע שזה String
        int n = count.get();
        System.out.println(s + " x" + n);

        // name.set(99); // לא יתקמפל: Box<String> מקבל רק מחרוזות
    }
}

בתוך Box, כל T הופך למה שהקורא סיפק. Box<String> היא קופסה שמחזיקה ומחזירה רק String. הקומפיילר דוחה את name.set(99) עוד לפני שהתוכנית רצה.

ה-<> הריק בצד ההשמה (diamond operator) מאפשר לקומפיילר להסיק את ארגומנט הטיפוס מהצד של ההצהרה, כך שלא צריך לכתוב <String> פעמיים.

מתודות גנריות

למתודה בודדת יכול להיות פרמטר טיפוס משלה, בלי תלות במחלקה. שימו את הפרמטר <T> לפני טיפוס ההחזרה:

import java.util.List;

public class Main {

    // <T> מצהיר על פרמטר הטיפוס; T הוא טיפוס האיבר
    static <T> T firstOrNull(List<T> items) {
        return items.isEmpty() ? null : items.get(0);
    }

    public static void main(String[] args) {
        List<String> words = List.of("alpha", "beta");
        List<Integer> nums = List.of(10, 20, 30);

        String w = firstOrNull(words);   // T מוסק כ-String
        Integer n = firstOrNull(nums);   // T מוסק כ-Integer
        System.out.println(w + " " + n);
    }
}

אף פעם לא מעבירים את T במפורש: הקומפיילר מסיק אותו מהארגומנט. מתודות גנריות הן הסיבה שכלים כמו Collections.sort או List.of נשארים בטוחים מבחינת טיפוסים עם כל טיפוס איבר.

פרמטרי טיפוס מוגבלים

לפעמים טיפוס גנרי הגיוני רק עבור חלק מהטיפוסים. extends מגביל את הפרמטר כך שאפשר לקרוא למתודות של הגבול. כאן T extends Number אומר ש-T הוא Number או כל תת-מחלקה שלו (Integer, Double, ...), ולכן doubleValue() זמינה:

import java.util.List;

public class Main {

    static <T extends Number> double sum(List<T> numbers) {
        double total = 0;
        for (T n : numbers) {
            total += n.doubleValue();   // חוקי כי T הוא לפחות Number
        }
        return total;
    }

    public static void main(String[] args) {
        System.out.println(sum(List.of(1, 2, 3)));        // Integers
        System.out.println(sum(List.of(1.5, 2.5)));       // Doubles
    }
}

שימו לב ש-extends כאן אומר "הוא תת-טיפוס של", והוא עובד גם למחלקות וגם לממשקים: <T extends Comparable<T>> נפוץ מאוד כשצריך להשוות בין איברים.

Wildcards: ? extends ו-? super

מלכודת עדינה: List<Integer> היא לא List<Number>, למרות ש-Integer הוא Number. Generics הם invariant. Wildcards מרפים את זה כשצריך רק לקרוא או רק לכתוב.

השתמשו ב-? extends T עבור יצרן שקוראים ממנו, וב-? super T עבור צרכן שכותבים אליו (כלל ה-"PECS": Producer Extends, Consumer Super):

import java.util.ArrayList;
import java.util.List;

public class Main {

    // קוראת Numbers: מקבלת List<Integer>, List<Double> וכו'
    static double total(List<? extends Number> nums) {
        double sum = 0;
        for (Number n : nums) sum += n.doubleValue();
        return sum;
    }

    // כותבת Integers: מקבלת List<Integer>, List<Number>, List<Object>
    static void addInts(List<? super Integer> dest) {
        dest.add(1);
        dest.add(2);
    }

    public static void main(String[] args) {
        List<Integer> ints = List.of(1, 2, 3);
        System.out.println(total(ints));      // עובד בזכות ? extends

        List<Number> bucket = new ArrayList<>();
        addInts(bucket);                       // עובד בזכות ? super
        System.out.println(bucket);
    }
}

רשימה מסוג ? extends Number מאפשרת לקרוא איברים כ-Number אבל לא להוסיף לה (הקומפיילר לא יכול לדעת את טיפוס האיבר המדויק). רשימה מסוג ? super Integer מאפשרת להוסיף Integer, אבל מה שקוראים ממנה חוזר כ-Object. בחרו את ה-wildcard שמתאים לכיוון הזרימה של הנתונים.

Type erasure והמגבלות שלו

Generics הם יכולת של זמן הקומפילציה. אחרי הקומפילציה פרמטר הטיפוס נמחק: בזמן ריצה Box<String> ו-Box<Integer> הם שניהם סתם Box. זה שומר על תאימות של generics לקוד ישן, אבל מטיל מגבלות אמיתיות.

// אף אחד מאלה לא מתקמפל: פרמטר הטיפוס לא קיים בזמן ריצה:
T value = new T();          // אי אפשר ליצור מופע של פרמטר טיפוס
T[] array = new T[10];      // אי אפשר ליצור מערך גנרי
if (list instanceof List<String>) { } // אי אפשר לבדוק את ארגומנט הטיפוס

מכיוון שהטיפוס נעלם בזמן ריצה, אי אפשר לשאול "מה היה T?" דרך reflection, ואי אפשר להעמיס מתודות שנבדלות רק בארגומנט הגנרי שלהן (foo(List<String>) ו-foo(List<Integer>) נמחקות לאותה חתימה). כשבאמת צריך את הטיפוס בזמן ריצה, העבירו Class<T> (type token) כפרמטר של בנאי או מתודה.

הבא בתור: ביטויי Lambda

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