الوراثة في جافا: extends وsuper وإعادة التعريف

الوراثة هي إعادة استخدام بنمط "is-a"

تتيح الوراثة لفئة جديدة أن تُبنى على فئة موجودة. الفئة الجديدة -الفئة الفرعية- تحصل تلقائيًا على حقول ودوال الفئة الأب، ثم تضيف أو تغيّر ما تحتاجه. تلجأ إليها عندما يكون نوع ما صنفًا أكثر تخصيصًا من نوع آخر: فالفئة Dog هي Animal، والفئة SavingsAccount هي BankAccount.

تكتبها باستخدام الكلمة المفتاحية extends. كل ما هو public أو protected في الفئة الأب يصبح متاحًا في الفئة الابن دون إعادة كتابته.

class Animal {
    String name;

    Animal(String name) { this.name = name; }

    void eat() { System.out.println(name + " is eating"); }
}

class Dog extends Animal {
    Dog(String name) { super(name); }   // تمرير name إلى الأعلى نحو Animal

    void bark() { System.out.println(name + " says woof"); }
}

public class Main {
    public static void main(String[] args) {
        Dog d = new Dog("Rex");
        d.eat();    // موروثة من Animal
        d.bark();   // مُعرّفة في Dog
    }
}

لم تُعلِن الفئة Dog قطّ عن name ولا عن eat()، ومع ذلك تملك كليهما. هذا هو جوهر الفكرة كلها: السلوك المشترك يعيش في مكان واحد.

super: الوصول إلى الفئة الأب

يجب أن يضمن باني الفئة الفرعية أن الفئة الأب تُهيَّأ أولًا. تفعل ذلك بـ super(...)، التي تستدعي باني الفئة الأب ويجب أن تكون أول عبارة في باني الفئة الفرعية. إن أغفلتها، تُدرج جافا ضمنيًا استدعاءً لباني الفئة الأب الذي لا يأخذ معاملات - وإذا لم يكن لدى الفئة الأب مثل هذا الباني، فلن تُترجَم الشيفرة.

class Account {
    double balance;

    Account(double opening) {
        balance = opening;
        System.out.println("Account opened with " + opening);
    }
}

class SavingsAccount extends Account {
    double rate;

    SavingsAccount(double opening, double rate) {
        super(opening);     // تشغيل باني Account أولًا
        this.rate = rate;
        System.out.println("Savings rate set to " + rate);
    }
}

public class Main {
    public static void main(String[] args) {
        new SavingsAccount(100.0, 0.05);
    }
}

يُظهر الخرج أن باني الفئة الأب يعمل قبل جسم الفئة الابن - فالبناء يتدفق من قمة التسلسل الهرمي نزولًا.

إعادة تعريف الدوال

تستطيع الفئة الفرعية استبدال دالة موروثة بإعادة تعريفها بنفس التوقيع. هذا هو إعادة التعريف، وينبغي أن تضع عليه دائمًا الوسم @Override. الوسم ليس إلزاميًا، لكنه يجعل المترجم يتحقق من أنك طابقت فعلًا دالةً في الفئة الأب - فهو يلتقط أخطاءً مطبعية مثل tostring() بدلًا من toString()، والتي كانت ستُنشئ بصمت دالةً جديدة تمامًا لولا ذلك.

class Animal {
    String speak() { return "..."; }
}

class Cat extends Animal {
    @Override
    String speak() { return "meow"; }
}

class Cow extends Animal {
    @Override
    String speak() { return "moo"; }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Cat(), new Cow(), new Animal() };
        for (Animal a : animals) {
            System.out.println(a.speak());   // كلٌّ يُشغّل نسخته الخاصة
        }
    }
}

رغم أن نوع المصفوفة هو Animal، فإن كل عنصر يُشغّل نسخته الخاصة من speak(). تختار جافا الدالة بناءً على الكائن الحقيقي أثناء التشغيل، لا بناءً على النوع المُعلَن للمتغير - وهذا هو أساس تعدد الأشكال.

استدعاء نسخة الفئة الأب باستخدام super.method()

إعادة التعريف لا تستلزم رمي عمل الفئة الأب. استخدم super.method() لتشغيل النسخة الموروثة ثم البناء عليها:

class Logger {
    void log(String msg) { System.out.println("[log] " + msg); }
}

class TimestampLogger extends Logger {
    @Override
    void log(String msg) {
        super.log("at t=0 " + msg);   // أعد استخدام الفئة الأب ثم وسّعها
    }
}

public class Main {
    public static void main(String[] args) {
        new TimestampLogger().log("server started");
    }
}

من دون super.، فإن استدعاء log داخل TimestampLogger.log سيستدعي نفسه ويدخل في تكرار لا نهائي. أما super. فتعني صراحةً "نسخة الفئة الأب".

الحقول الموروثة والوصول

ترى الفئة الفرعية أعضاء الفئة الأب من نوع public وprotected، لكنها لا ترى أعضاءها من نوع private. تظل حقول private موجودة في الكائن - تستطيع دوال الفئة الأب نفسها التعامل معها - لكن الفئة الفرعية لا تستطيع الإشارة إليها مباشرةً. استخدم protected عندما تريد أن تصل إليه الفئات الفرعية مع إبقاء العضو مخفيًا عن الشيفرة غير المرتبطة.

class Base {
    private int secret;      // غير مرئي للفئات الفرعية
    protected int shared;    // مرئي للفئات الفرعية
}

class Derived extends Base {
    void demo() {
        shared = 5;          // OK
        // secret = 5;       // خطأ في الترجمة - private ضمن Base
    }
}

ولهذا أيضًا كثيرًا ما يتوجب على باني الفئة الفرعية استدعاء super(...): فهو السبيل الوحيد لتهيئة الحالة الخاصة (private) للفئة الأب.

إيقاف الوراثة باستخدام final

أحيانًا ينبغي ألا تُورَّث فئة على الإطلاق - فالفئة String هي final لهذا السبب بالضبط. وسم فئة بأنها final يمنع إنشاء فئات فرعية منها؛ ووسم دالة بأنها final يمنع إعادة تعريفها مع السماح بوراثة الفئة رغم ذلك.

final class Constants { }            // لا يمكن اشتقاق فئات فرعية منها

class Config {
    final void load() { }            // يمكن للفئات الفرعية وراثة Config
                                     // لكن لا يمكنها إعادة تعريف load()
}

الجأ إلى final عندما يجب أن يكون سلوك الفئة مضمونًا وثابتًا عبر البرنامج كله - فهو إشارة مقصودة بمعنى "لا تورّث"، وليس الخيار الافتراضي.

خطأ شائع: فضّل التركيب عندما لا تكون العلاقة "is-a"

الوراثة مُغرية لأنها تعيد استخدام الشيفرة، لكنها تربط الفئة الابن بالفئة الأب ربطًا وثيقًا. إن لم تكن العلاقة "is-a" حقيقية - كأن تكون فئة Car تحتاج صدفةً إلى Engine - فلا تجعل Car extends Engine. السيارة تملك محركًا، وليست محركًا. اعمل على نمذجة ذلك بحقل (تركيب) بدلًا من ذلك:

class Car {
    private Engine engine = new Engine();   // Car تملك Engine (HAS-A)

    void start() { engine.ignite(); }
}

استخدم الوراثة فقط عندما تكون الفئة الفرعية حقًا صورة متخصصة من الفئة الأب وتريد أن ترث سلوكها وتستبدله في آنٍ معًا.

التالي: الواجهات

تمنحك الوراثة بـ extends فئة أبًا واحدةً وتنفيذًا مشتركًا. لكن الفئة لا يمكنها أن ترث سوى فئة واحدة فقط - فكيف إذًا تمنح فئاتٍ غير مترابطة قدرةً مشتركة؟ لهذا تُوجد الواجهات: عقد تستطيع فئات عديدة تنفيذه، وهو موضوع الصفحة التالية.