6 فروقات جوهرية بين Abstract Class و Interface في أسئلة AP Computer Science A

في عالم البرمجة كائنية التوجه (OOP)، هناك مفهومان يُسببان خلطاً متكرراً بين طلاب AP Computer Science A: الفئات التجريدية (Abstract Classes) والواجهات (Interfaces). كثير من الطلاب يعرفون تعريفاتهما النظرية، لكنهم يفتقرون إلى الفهم العملي الذي يُمكّنهم من تمييز متى يستخدم كلاً منهما داخل أسئلة الامتحان. هذا الفهم ليس ترفاً أكاديمياً؛ بل هو مهارة تحليلية تُختبر مباشرة في قسمَي الاختيار من متعدد (MCQ) وأسئلة الإجابة الحرة (Free Response Questions).

الامتحان يتوقع منك ليس فقط أن تُعرّف هذين المفهومين، بل أن تُحلّل سيناريوهات برمجية وتُحدد أي بنية تُناسبها، وأن تُتوقع مخرجات الأكواد التي تستخدم هياكل وراثة معقدة. في هذا المقال، سنبني فهمك من الصفر حتى مستوى القدرة على التعامل مع أي سؤال امتحاني يتناول هذين المفهومين.

ما المقصود بـ Abstract Class في Java؟

الفئة التجريدية هي فئة لا يمكن إنشاء كائن (object) منها مباشرة، بل تُستخدم كقاعدة تصنيف (classification template) لفئات فرعية ترث منها. يمكن أن تحتوي على:

• طرق تجريدية (abstract methods): توقيعات_methods_ بدون تنفيذ، يجب على أي فئة فرعية غير تجريدية إعادة تنفيذها.
• طرق مُنجزة (concrete methods): implementations كاملة يمكن للفئات الفرعية استخدامها مباشرة أو إعادة تجاوزها (override).
• متغيرات instance: أي نوع من المتغيرات بما فيها final وstatic.
• باني (constructor): يمكن أن يحتوي على منطق تهيئة.

العلاقة مع الفئات الفرعية تكون من نوع is-a (علاقة تصنيف)، أي أن الفئة الفرعية هي نوع محدد من الفئة التجريدية.

ما المقصود بـ Interface في Java؟

الواجهة في Java هي عقد (contract) يُعرّف مجموعة من التوقيعات_methods_ التي يجب على أي فئة تُنفّذها (implement) إعادة تجاوزها. أهم خصائص الواجهة:

• منذ Java 8، يمكن أن تحتوي على طرق افتراضية (default methods) مع implementation افتراضي.
• منذ Java 9، يمكن أن تحتوي على طرق خاصة (private methods) تُسهّل إعادة استخدام الكود داخل الواجهة نفسها.
• لا تحتوي على متغيرات instance؛ ما تحتويه هو ثوابت (public static final) فقط.
• لا تحتوي على constructors.
• الفئة الواحدة يمكن أن تُنفّذ عدة واجهات في الوقت ذاته.

الفئة التي تُنفّذ واجهة تُقرّ بأنها تتعهد بتقديم تنفيذ لجميع الطرق غير الافتراضية فيها — أو أن تكون هي نفسها abstract. العلاقة تكون من نوع can-do أو has-a capability، أي أن الفئة تُظهر قدرة معينة.

متى تختار Abstract Class ومتى تختار Interface؟

السؤال الأكثر تكراراً في الامتحان ليس "عرّف" بل "أيٌّ منهما تستخدم في هذا السيناريو؟". القاعدة الذهبية بسيطة:

استخدم abstract class عندما تريد بناء تسلسل هرمي (hierarchy) لعلاقة is-a وتريد أن تشارك فيه حقولاً (fields) وطرقاً مُنجزة. واستخدم interface عندما تريد تعريف قدرة (capability) مستقلة عن مكان الفئة في التسلسل الهرمي، أو عندما تريد أن تُنفّذ عدة عقود في آن واحد.

لنأخذ مثالاً عملياً من سياق AP Computer Science A:

فئة BankAccount تُمثّل حساباً مصرفياً بجميع خصائصه (رقم الحساب، الرصيد، اسم صاحب الحساب) وسلوكياته المُنجزة (إيداع، سحب). تريد الآن إضافة قدرة "القابلية للتحويل" (Transferable) تطبّقها عدة فئات مختلفة: حساب مصرفي، محفظة إلكترونية، حساب استثماري. هذه القابلية لا تنتمي بشكل طبيعي إلى أي تسلسل هرمي واحد.

الحل البرمجي: interface اسمها Transferable تُعرّف طريقة transfer(BankAccount other, double amount)، بينما abstract class تُحافظ على التسلسل الهرمي للحسابات. الفئة Concrete مثل SavingAccount extends BankAccount implements Transferable تحتفظ بالوراثة من الفئة التجريدية وتُظهر القدرة من الواجهة.

في Java، فئة واحدة يمكنها أن extend فئة واحدة فقط، لكنها يمكنها أن implement عدة واجهات في الوقت ذاته. هذا يعني أن:

• Abstract class = تصميم تسلسلي هرمي (أب واحد فقط).
• Interface(s) = تصميم قائم على القدرات المتعددة (عدة عقود متوازية).

التعددية الشكلية (Polymorphism): كيف تُفعّل Abstract Classes و Interfaces معاً؟

التعددية الشكلية هي المبدأ الذي يجعل هذه العلاقة مفيدة فعلياً. في Java، متغير من نوع فئة تجريدية أو واجهة يمكن أن يُشير (reference) إلى كائن من أي فئة فرعية تُنفّذها. هذا يُتيح كتابة أكواد مرنة تعمل مع مجموعة واسعة من الأنواع.

مثال تطبيقي:

لديك واجهة Playable بطريقتين: play() و pause(). الفئة VideoGame implements Playable تُنفّذهما بتحكم游戏. والفئة MusicPlayer implements Playable تُنفّذهما بتشغيل موسيقى. الآن يمكنك كتابة:

Playable[] items = new Playable[2];
items[0] = new VideoGame();
items[1] = new MusicPlayer();
for (Playable p : items) { p.play(); }

ما يحدث هنا: في وقت التشغيل (runtime)، يُحدَّد النظام النوع الفعلي للكائن ويُنادي التنفيذ الصحيح. هذا هو جوهر Polymorphism.

في الامتحان، ستجد أسئلة تختبر فهمك لهذا المبدأ بطرق مثل: "إذا كان List l = new ArrayList()، فأي من الأسطر التالية يُنتج خطأ编译؟" — الإجابة تتطلب معرفة أن ArrayList implements List، وأن List extends Collection.

تحليل أنماط الأسئلة الامتحانية

أسئلة AP Computer Science A التي تتناول Abstract Classes و Interfaces تظهر في نمطين رئيسيين:

الأسئلة النظرية المفاهيمية

تطرح عليك سيناريو برمجي وتطلب تحديد أي من التالي صحيح:

مثال: "أيٌّ مما يلي صحيح بالنسبة لـ Interface في Java؟" — الخيارات تتضمن: (أ) يمكن أن تحتوي على متغيرات instance، (ب) يمكن للفئة أن extend أكثر من interface واحد، (ج) يمكن أن تحتوي على طرق without implementation (قبل Java 8)، (د) يمكن أن يكون لها constructor.

الجواب الصحيح يتطلب معرفة أن (ج) صحيح — قبل Java 8 كانت الواجهات تحتوي فقط على signatures_methods_ بدون implementations. بعد Java 8، يمكن للواجهات أن تحتوي على default methods و static methods، مما وسّع نطاق استخداماتها.

الأسئلة البرمجية التحليلية

تعرض عليك شريحة كود وتطلب تحديد مخرجاتها أو اكتشاف الخطأ:

مثال: فئة abstract class Shape بطريقتين abstract: double getArea() و String getName(). فئة Circle extends Shape تُعيد تنفيذ getArea() فقط. هل هذا مقبول؟

الجواب: لا. لأن Circle ليست abstract، يجب أن تُعيد تنفيذ جميع الطرق التجريدية الموروثة — وإلا ستحصل على خطأ编译. هذا النمط يُختبر بكثرة في الامتحان.

الأخطاء الشائعة وكيفية تجنبها

خلال تحليل مئات الأسئلة الامتحانية، وجدت أن أخطاء الطلاب تتركز في أنماط متكررة يمكن تعلم تجنبها:

الخطأ الأول: الخلط بين extends و implements

كثير من الطلاب يكتبون class Dog extends Animal implements Serializable ثم يُخطئون في اختيار كلمة محجوزة. القاعدة: استخدم extends للفئات وimplements للواجهات. لا تخلط بينهما ولا تستخدم implements لفئة تجريدية — لأن extend كافية عندما ترث من فئة تجريدية.

الخطأ الثاني: نسيان إعادة تجاوز الطرق التجريدية

عند تنفيذ واجهة أو التوسع في فئة تجريدية، يجب أن تُعيد تجاوز كل الطرق التجريدية ما لم تكن فئتك نفسها abstract. إذا نسيت طريقة واحدة، لن يُجمّع الكود. في الامتحان، ستجد أسئلة تطلب منك "اكتب فئة تتحقق من Contract التالي" — افهم أن المطلوب هو إعادة التنفيذ الكامل.

الخطأ الثالث: افتراض أن المتغيرات في الواجهة غير قابلة للتغيير

كل متغير في interface هو ضمنياً public static final، أي constant. لا يمكنك تغيير قيمته في أي فئة تُنفّذه. إذا حاولت مثلاً كتابته داخل method في الفئة المُنفّذة، ستحصل على خطأ compile. استخدم هذا في الامتحان لتحديد مخرجات الأكواد التي تحتوي على赋值 لثوابت الواجهة.

الخطأ الرابع: تجاهل مبدأ التقنين (Encapsulation) عند التعامل مع Abstract Classes

الـ abstract class يمكن أن تحتوي على private fields، و subclasses لا تستطيع الوصول إليها مباشرة. في الامتحان، عندما تجد سؤالاً يسأل عن "ما مخرجات هذا الكود؟" ويحتوي على abstract class مع private field، تأكد أن الـ subclass لا تستطيع الوصول إليه — والإجابة لن تتضمن مباشرةً طباعة ذلك الـ field.

الخطأ الخامس: الخلط بين نوع المتغير ونوع الكائن

هذا من أصعب المفاهيم للطلاب. المتغير declaration type يُحدد ما يمكن استدعاؤه، والكائن actual type يُحدد أي implementation يُنفَّذ. في:

Shape s = new Circle(5.0);
System.out.println(s.getArea());

هنا: نوع المتغير هو Shape (ويمكنه استدعاء getArea() لأن getArea() طريقة تجريدية موروثة)، ونوع الكائن هو Circle (والذي يُعيد تنفيذ getArea()). السؤال في الامتحان: "ما نوع المتغير s؟" — الجواب: Shape. ليس Circle. هذا الفرق حاسم في أسئلة polymorphism.

الخطأ السادس: الخلط بين Interface و Abstract Class عند استخدام ArrayList

من أكثر السيناريوهات تكراراً في الامتحان:

ArrayList<Shape> shapes = new ArrayList<>();
shapes.add(new Circle(3.0));
shapes.add(new Square(4.0));

هنا Circle و Square كلاهما extends Shape. لكن لو كان المطلوب هو أن كل عنصر implements Comparable، لكان عليك كتابة ArrayList<Comparable>. الخطأ الشائع: استخدام نوع الفئة بدلاً من نوع الواجهة عند التعامل مع collections — تأكد دائماً أن الكائن الفعلي implements الواجهة المستخدمة في Declaration.

جدول مقارنة شامل: Abstract Class vs Interface

استراتيجية المراجعة قبل الامتحان

للتحضير الأمثل، اتبع هذه الخطة المتدرجة:

أولاً، تأكد من فهمك للاختلافات في الجدول أعلاه حتى تُجيب على أي سؤال نظري. ثم انتقل إلى كتابة أكواد صغيرة بأنواع مختلفة: اكتب abstract class مع طريقتين تجريديتين وطريقة مُنجزة واحدة، ثم extendها بفئة concrete، ثم اكتب interface و implementه في فئة أخرى، ثم اكتب فئة ثالثة extend الأولى وت implement الثانية في آن واحد — هذا السيناريو الأخير يُختبر كثيراً.

بعد ذلك، احلل أسئلة امتحانية سابقة (Past Papers) وتحديداً السنوات من 2020 فما بعد التي تطبق صيغة Digital SAT. ابحث عن الأسئلة التي تطلب تحديد أي من التالي يصح عن abstract class أو interface، ثم حاول تحليل مخرجات أكواد polymorphism التي تستخدم أنواعاً تجريدية.

أخيراً، أثناء الامتحان، عندما تواجه سؤالاً عن abstract class أو interface، اقرأ السيناريو برمجياً: هل هناك علاقة is-a واضحة (تراث) أم قدرة مستقلة (واجهة)؟ هل تريد مشاركة implementation (abstract class) أم فقط تعريف contract (interface)؟ الإجابة على هذين السؤالين ستُوجّهك بسرعة نحو الخيار الصحيح.

الخلاصة والخطوات التالية

التمييز بين Abstract Class و Interface ليس مجرد مفهوم نظري يُختبر في الامتحان — بل هو أداة تصميم أساسية في Java تُمكّنك من بناء أنظمة مرنة وقابلة للتوسع. القاعدة التطبيقية الأساسية: استخدم abstract class عندما تريد بنية هرمية مشتركة، واستخدم interface عندما تريد قدرات مرنة مستقلة عن التسلسل الهرمي.

في الامتحان، الانتباه إلى الاختلافات في الصياغة (extends vs implements)، ونطاق المتغيرات (final vs mutable)، وعدد الأنواع المسموح (واحد vs عدة) كفيل بتوجيهك إلى الإجابة الصحيحة في معظم الأسئلة. تدرّب على تحويل سيناريوهات وصفية إلى تصميمات برمجية — هذه المهارة هي ما يُميّز الطالب الجيد في AP Computer Science A.

Frequently asked questions