تصميم فئات الطلاب في البرمجة الكائنية

في مشروع الفصل الدراسي، طلب مني إنشاء ثلاثة أكواد برمجية: الصف الطالب، الطالب الجامعي، والطالب الدراسات العليا. بدأنا بتصميم فئة الطالب، التي تحتوي على ثلاثة معاملات: الاسم (سلسلة نصية)، ونقاط الاختبار (مصفوفة أعداد صحيحة)، والدرجة (سلسلة نصية). تم تصميم بناء فارغ يعين الاسم والدرجة إلى سلاسل نصية فارغة، وتم إنشاء مصفوفة نقاط الاختبار بثلاثة أصفار. كما تم إنشاء بناء آخر يأخذ الاسم، نقاط الاختبار، والدرجة كمعاملات. ثلاث طرق تمثل: getName() – تُرجع الاسم، وgetGrade() – تُرجع الدرجة، وsetGrade() – تقوم بتعيين الدرجة، وgetTestAverage() – تُرجع متوسط نقاط الاختبار. تم تصميم طريقة computeGrade() لحساب الدرجة، حيث إذا كان المتوسط أكبر من أو يساوي 65، يتم تعيين الدرجة إلى “ناجح”، وإلا يتم تعيينها إلى “رسوب”.

تم تصميم الفئة الثانية باسم UnderGrad، وهي فئة فرعية من الطالب. تم إنشاء بناء فارغ وآخر يأخذ الاسم، نقاط الاختبار، والدرجة كمعاملات. كما تم تعليمنا بتجاوز طريقة computeGrade() لتحديد أن الطالب UnderGrad يجب أن يحصل على 70 أو أكثر ليكون ناجحاً.

أما بالنسبة للفئة الثالثة، فهي فئة فرعية من الطالب تحت اسم GradStudent. تم إنشاء متغير فردي MyGradID من نوع int، حيث تم تصميم بناء فارغ يستدعي البناء الأساسي ويعين قيمة MyGradID إلى صفر. وتم إنشاء بناء آخر يأخذ الاسم، نقاط الاختبار، والدرجة، بالإضافة إلى رقم التعريف كمعاملات. تم تصميم طريقة getId() لتُرجع رقم التعريف. وتم تجاوز طريقة computeGrade() لتعيين الدرجة بناءً على معايير محددة، حيث يُعتبر المتوسط الذي يزيد عن 65 درجة “ناجحًا”، وإذا كان المتوسط أعلى من 90، يكون الطالب قد نجح بتمييز.

الكود الذي قدمته للفئة GradStudent يحتوي على بعض الأخطاء. في البناء الثاني، يجب أن يكون اسم البناء هو نفس اسم الفئة، ولكنك استخدمت “GradStudent” بدلاً من “public GradStudent”. كما أن MyGradId يجب أن يكون معرفًا بطريقة صحيحة. يُفضل استخدام “this” لتمييز بين المتغيرات الفردية والمعاملات. كما أنه يجب تحديد نوع الدرجة في طريقة computeGrade(). اليك الكود المعدل:

javaCopy code
public class GradStudent extends Student {
    private int MyGradID;

    public GradStudent() {
        super();
        MyGradID = 0;
    }

    public GradStudent(String n, int[] tests, String g, int id) {
        super(n, tests, g);
        this.MyGradID = id;
    }

    public int getId() {
        return this.MyGradID;
    }

    @Override
    public void computeGrade() {
        if (getTestAverage() >= 65) {
            super.setGrade("Pass");
        } else if (getTestAverage() > 90) {
            super.setGrade("Pass with distinction");
        } else {
            super.setGrade("Fail");
        }
    }
}

أتمنى أن يكون هذا الشرح قد ساعدك في فهم كيفية تصميم هذه الفئات وتجاوز الطرق بشكل صحيح.

تتيح لي الفرصة التوسع في المعلومات حول التصميم البرمجي للفئات المختلفة. سنركز على الفئات Student، UnderGrad، وGradStudent، ونقوم بتوضيح بعض النقاط الإضافية.

بدأنا بتصميم فئة Student، حيث تم توفير بنائين، الأول فارغ لتعيين القيم الافتراضية، والثاني لتحديد القيم عبر المعاملات. تم أيضاً تصميم طرق للوصول وتعيين الاسم، الدرجة، ومتوسط نقاط الاختبار. وأخيرًا، تم تصميم طريقة computeGrade() لتحديد مصير الطالب بناءً على متوسط الدرجات.

تم إنشاء الفئة UnderGrad كفئة فرعية من Student، وقد تم تجاوز طريقة computeGrade() في UnderGrad لتحديد أن الطالب يحتاج إلى درجة 70 أو أعلى ليكون ناجحًا، وإلا فإنه يرسب.

أما بالنسبة للفئة GradStudent، فقد تم إضافة متغير فردي إضافي MyGradID لتمييز الطلاب الدراسات العليا. تم تصميم بنائين، أحدهما فارغ لتعيين القيم الافتراضية والآخر لتحديد القيم عبر المعاملات. ثم تم تجاوز طريقة computeGrade() لتحديد مصير الطالب، حيث تعيين الدرجة بناءً على معايير محددة، مع مراعاة درجة التمييز إذا كان متوسط نقاط الاختبار أعلى من 90.

لضمان الأمان وعدم الوصول المباشر إلى المتغيرات الخاصة في الفئة الأساسية Student، تم استخدام مفهوم الحقول والطرق الخاصة. هذا يعني أن المتغيرات تكون خاصة بالفئة وليس من الممكن الوصول إليها مباشرة من خلال كائنات الفئات الفرعية.

في النهاية، هذا التصميم يعكس مفهوم الوراثة والتجاوز في البرمجة الكائنية، حيث يمكن للفئات الفرعية توسيع وتعديل السلوك والخصائص الموروثة من الفئة الأساسية.