מחלקות אבסטרקטיות ב-Java: מילת המפתח abstract

מה זו מחלקה אבסטרקטית

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

הרעיון הוא לרכז במקום אחד את כל מה שמשותף לתתי-המחלקות, ולחייב כל תת-מחלקה להשלים את החלקים שבאמת שונים.

abstract class Animal {
    private final String name;

    Animal(String name) { this.name = name; }   // בנאי משותף

    String getName() { return name; }            // מתודה משותפת וגמורה

    abstract String sound();                     // בלי גוף: כל תת-מחלקה מחליטה
}

class Dog extends Animal {
    Dog(String name) { super(name); }
    String sound() { return "Woof"; }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog("Rex");
        System.out.println(a.getName() + " says " + a.sound());
    }
}

Animal מגדירה את getName() פעם אחת לכל תתי-המחלקות ומצהירה על sound() כ-abstract: מתודה עם חתימה אבל בלי גוף, ש-Dog חייבת לספק.

אי אפשר ליצור מופע של מחלקה אבסטרקטית

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

Animal a = new Animal("???");   // error: Animal is abstract; cannot be instantiated

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

מתודות אבסטרקטיות מחייבות את תתי-המחלקות להחליט

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

abstract class Shape {
    abstract double area();                       // כל צורה חייבת להגדיר את זה

    void describe() {                             // משותפת, נכתבת פעם אחת
        System.out.printf("%s with area %.2f%n",
            getClass().getSimpleName(), area());
    }
}

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) {
        Shape[] shapes = { new Circle(2), new Square(3) };
        for (Shape s : shapes) {
            s.describe();                         // קוראת אוטומטית ל-area() הנכונה
        }
    }
}

describe() נכתבת פעם אחת ב-Shape, ובכל זאת קוראת ל-area() של כל תת-מחלקה. המחלקה האבסטרקטית מספקת את השלד המשותף; תתי-המחלקות מספקות את הפרטים.

מצב משותף ובנאים

בניגוד לממשק מסורתי, מחלקה אבסטרקטית יכולה להחזיק שדות מופע ולהגדיר בנאים. הבנאי אף פעם לא יוצר Animal או Shape בעצמו: הוא רץ דרך super(...) כשנוצרת תת-מחלקה, ומאתחל את המצב המשותף.

abstract class Account {
    private double balance;

    Account(double opening) { this.balance = opening; }

    double getBalance() { return balance; }

    void deposit(double amount) { balance += amount; }

    abstract double interestRate();               // שונה לפי סוג החשבון

    void applyInterest() { balance += balance * interestRate(); }
}

class Savings extends Account {
    Savings(double opening) { super(opening); }
    double interestRate() { return 0.05; }
}

public class Main {
    public static void main(String[] args) {
        Account acc = new Savings(1000);
        acc.deposit(500);
        acc.applyInterest();
        System.out.printf("balance: %.2f%n", acc.getBalance());
    }
}

השדה balance, המתודה deposit והמתודה applyInterest נמצאים במקום אחד. רק המדיניות שבאמת משתנה, interestRate(), נשארת אבסטרקטית. הבנאי של תת-מחלקה חייב לקרוא ל-super(...) כדי לאתחל את המצב שעבר בירושה.

מלכודת: שילוב של abstract ו-final

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

abstract final class Bad { }        // error: abstract and final conflict

abstract class Base {
    abstract final void f();        // error: an abstract method can't be final
}

מחלקה אבסטרקטית מול ממשק

יש ביניהם חפיפה, ולכן הבחירה תלויה במה שצריך לשתף:

• מחלקה אבסטרקטית: השתמשו בה למחלקות קרובות שחולקות מצב וקוד. גם Savings וגם Checking מרחיבות את Account, ויורשות את השדה balance ואת הלוגיקה של deposit. מחלקה מרחיבה רק מחלקה אחת.
• ממשק: השתמשו בו ליכולת שמחלקות לא קשורות יכולות לחלוק. Bird ו-Airplane יכולות להיות שתיהן Flyable בלי לחלוק שום מימוש. מחלקה יכולה לממש הרבה ממשקים.

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

הבא בתור: פולימורפיזם

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