// Question 01

Object-Oriented Thinking — Composition & Association

Objective: Design a system that emphasizes object collaboration and data encapsulation using Composition and Association, without relying on inheritance or interfaces.

في هذا السؤال، المطلوب تصميم نظام حجز رحلات جوية (Flight Reservation System) يُدير العلاقة بين الرحلات والركاب والطيارين من خلال تعاون الكائنات مع بعضها. يعتمد النظام على مفهومَي Composition (حيث تمتلك الرحلة قائمتها الخاصة من الركاب) وAssociation (حيث تُربط كل رحلة بطيار واحد من الخارج). لا يُستخدم الوراثة أو الواجهات في هذا السؤال.

class Passenger
  • F ثلاثة حقول: String name، String passportNumber، و double baggageWeight لتمثيل اسم الراكب ورقم جواز سفره ووزن أمتعته.
  • C مُنشئ (Constructor) يُهيّئ الحقول الثلاثة دفعةً واحدة عند إنشاء الكائن.
  • G دوال getter مناسبة للوصول إلى كل حقل من الخارج مع الحفاظ على مبدأ التغليف (Encapsulation).
class Pilot
  • F ثلاثة حقول: String name، String licenseID، و int experienceHours لتمثيل هوية الطيار وخبرته.
  • C مُنشئ يُهيّئ جميع الحقول عند إنشاء الكائن.
  • M دالة لعرض بيانات اعتماد الطيار (Pilot Credentials) تطبع اسمه ورقم رخصته وساعات خبرته.
class Flight
  • Composition: تحتضن الرحلة قائمتها الخاصة ArrayList<Passenger> التي تُنشأ داخلياً — لا تُمرَّر من الخارج.
  • Association: تُربط كل رحلة بكائن Pilot واحد يُمرَّر من الخارج ولا تمتلكه الرحلة بشكل حصري.
  • F حقول: String flightNumber، String destination، و final int MAX_CAPACITY لتحديد رقم الرحلة ووجهتها وحدها الأقصى من الركاب.
  • M addPassenger(Passenger p) — تُضيف راكباً إلى القائمة فقط إذا لم تبلغ الرحلة طاقتها القصوى.
  • M calculateTotalBaggage() — تجمع أوزان أمتعة جميع الركاب وتُعيد الإجمالي.
  • M printManifest() — تطبع تفاصيل الرحلة، بيانات الطيار، وقائمة كاملة بأسماء الركاب.
// Question 02

Inheritance & Polymorphism — Dynamic Systems

Objective: Implement a financial account hierarchy to demonstrate the use of Inheritance, Method Overriding, and Dynamic Binding.

يتمحور هذا السؤال حول بناء هرمية حسابات بنكية تُظهر قوة الوراثة والتعدد الشكلي. كل نوع حساب يرث سلوكاً مشتركاً من كلاس أساسي Account، ثم يُعيد تعريف سلوك السحب بطريقة تتناسب مع طبيعته. يُختبر التعدد الشكلي عبر دالة audit التي تعمل على مصفوفة من الأنواع المختلفة وتستدعي الدالة الصحيحة تلقائياً في وقت التشغيل (Dynamic Binding).

class Account — الكلاس الأساسي
  • F حقلان: int id و double balance يُمثّلان رقم الحساب ورصيده الحالي.
  • M withdraw(double amount) — دالة السحب الافتراضية المراد تجاوزها في الكلاسات الفرعية.
  • M deposit(double amount) — تُضيف المبلغ إلى الرصيد مباشرةً دون قيود.
  • M toString() — تُعيد تمثيلاً نصياً للحساب يتضمن المعرّف والرصيد.
extends Account SavingsAccount
  • يرث جميع حقول ودوال Account دون إضافة حقول جديدة.
  • @ يُعيد تعريف withdraw: يمنع العملية كلياً إذا كان المبلغ المطلوب أكبر من الرصيد الحالي، لضمان عدم سلبية الرصيد في أي وقت.
extends Account CheckingAccount
  • F حقل إضافي double overdraftLimit يحدد الحد الأقصى المسموح به للسحب فوق الرصيد الصفري.
  • @ يُعيد تعريف withdraw: يُجيز العملية طالما أن الرصيد بعد السحب لا يتخطى حد السحب على المكشوف (أي: balance - amount ≥ -overdraftLimit).
⚡ Dynamic Processing — audit()
  • S دالة static void audit(Account[] accounts) تتلقى مصفوفة من الحسابات المختلطة الأنواع.
  • D تتكرر على المصفوفة وتستدعي withdraw لكل عنصر — يتكفّل الـ Dynamic Binding تلقائياً باستدعاء الإصدار الصحيح حسب النوع الفعلي للكائن.
  • I تستخدم عامل instanceof للكشف عن كائنات CheckingAccount وطباعة قيمة overdraftLimit الخاصة بها تحديداً.
// Question 03

Abstraction & Interfaces — The Geometric System

Objective: Build a system for managing geometric shapes using Abstract Classes, Interfaces (Comparable, Cloneable, and custom), and Deep Cloning.

يستهدف هذا السؤال بناء نظام إدارة أشكال هندسية يعتمد على ثلاثة طبقات: كلاس مجرد يُعرّف السلوك المشترك، واجهات تُضيف قدرات إضافية (التلوين، المقارنة، النسخ العميق)، وكلاس ملموس يُجمع كل شيء. يتجلّى مبدأ Abstraction في إخفاء التفاصيل الهندسية خلف عقود واضحة تُحدّدها الواجهات.

abstract class GeometricObject
  • F حقلان خاصان: private String color و boolean filled لتمثيل لون الشكل وحالة ملئه.
  • A دالتان مجردتان: getArea() و getPerimeter() تُجبر كل كلاس فرعي على توفير تنفيذه الخاص للمساحة والمحيط.
  • I ينفّذ Comparable<GeometricObject> — يُقارن الكائنات بناءً على مساحتها المحسوبة، ما يُتيح الترتيب التلقائي.
interface Colorable
  • واجهة بسيطة تحتوي على دالة واحدة: void howToColor() تُلزم الكلاسات المنفّذة بتوضيح كيفية تلوين الشكل.
extends / implements Square
  • يمتد من GeometricObject وينفّذ كلاً من Colorable و Cloneable.
  • F حقل خاص واحد: private double side يمثّل طول ضلع المربع.
  • @ يُعيد تعريف getArea() لتُعيد side * side، و getPerimeter() لتُعيد 4 * side.
  • @ ينفّذ howToColor() لطباعة: "Color all four sides."
  • @ يُعيد تعريف clone() لإجراء نسخ عميق (Deep Copy) — يُنشئ كائناً جديداً مستقلاً تماماً بدلاً من مجرد نسخ المرجع.
class ShapeManager — إدارة البيانات
  • M sortShapes(ArrayList<GeometricObject> list) — ترتّب قائمة الأشكال تصاعدياً وفق ترتيبها الطبيعي (المساحة) مستعينةً بـ Comparable المُنفَّذ في الكلاس الأساسي.
  • M sumArea(GeometricObject[] list) — تُكرّر على مصفوفة الأشكال وتُعيد مجموع مساحاتها الكلي.