البرمجة الكائنية في Java: فهم الكلاسات والوراثة والتغليف

تساعد البرمجة الكائنية على تنظيم البرامج التي تتعامل مع كيانات لها بيانات وسلوك، مثل الحساب البنكي أو المنتج أو المستخدم. لكن حفظ تعريفات class وinheritance لا يكفي لفهمها. يحتاج المطور إلى معرفة متى يجمع البيانات مع الدوال، ومتى يخفي الحالة الداخلية، ومتى تكون الواجهة أو التركيب أفضل من الوراثة. سنبني مثالاً صغيراً لحساب بنكي بلغة Java، ونستخدم private لمنع التعديل العشوائي، ثم نفسر سبب كل قرار. الهدف هو كتابة نموذج يمكن اختباره وتوسيعه، لا تحويل كل فكرة إلى سلسلة وراثة طويلة.

الفكرة الأساسية

الكلاس قالب يصف الخصائص والعمليات، والكائن نسخة فعلية منه. يسمح التغليف بإخفاء الحالة وتحديد الطرق التي تغيرها، مثل deposit وwithdraw. لا ينبغي أن يتمكن أي جزء من البرنامج من جعل الرصيد سالباً بمجرد تعديل متغير عام. تستخدم الواجهة لتحديد ما يستطيع الكائن فعله من دون كشف طريقة التنفيذ. أما الوراثة فتنشئ علاقة is-a، ولذلك لا تناسب كل مشاركة للكود. إذا كانت العلاقة مجرد استخدام، فغالباً يكون التركيب أبسط.

مثال برمجي عملي

public final class BankAccount {
    private final String owner;
    private long balanceCents;

    public BankAccount(String owner, long openingBalanceCents) {
        if (owner == null || owner.isBlank()) {
            throw new IllegalArgumentException("Owner is required");
        }
        if (openingBalanceCents < 0) {
            throw new IllegalArgumentException("Balance cannot be negative");
        }
        this.owner = owner;
        this.balanceCents = openingBalanceCents;
    }

    public void deposit(long amountCents) {
        if (amountCents <= 0) throw new IllegalArgumentException("Invalid amount");
        balanceCents += amountCents;
    }

    public boolean withdraw(long amountCents) {
        if (amountCents <= 0 || amountCents > balanceCents) return false;
        balanceCents -= amountCents;
        return true;
    }

    public long getBalanceCents() {
        return balanceCents;
    }
}

شرح المثال

جعلنا الكلاس final لأن المثال لا يحتاج إلى السماح بالوراثة منه، وأخفينا owner وbalanceCents باستخدام private. خزنا المبلغ بالسنت كعدد صحيح لتجنب أخطاء الأعداد العشرية في العمليات المالية. يفحص constructor المدخلات قبل إنشاء الكائن، بينما تمنع deposit قيمة غير موجبة. تعيد withdraw false عندما لا يكفي الرصيد بدلاً من تعديله إلى قيمة غير صالحة. الدالة getBalanceCents توفر قراءة مضبوطة، ولا توفر setter يغير الرصيد مباشرة.

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

طريقة العمل قبل كتابة الكود

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

قسّم المشكلة إلى أجزاء صغيرة، واجعل كل جزء مسؤولاً عن قرار واحد قدر الإمكان. يمكن أن تكون الأجزاء دوال، أو مكونات، أو طبقات منفصلة بحسب التقنية. لا يعني التقسيم إنشاء ملفات كثيرة، بل يعني أن تعرف أين تبحث عندما يحدث الخطأ. سجّل الافتراضات المهمة بجملة قصيرة، مثل أن القائمة مرتبة أو أن السعر غير سالب، ثم تحقق منها في المكان المناسب بدلاً من الاعتماد على الذاكرة.

اختبار المثال في حالات مختلفة

لا تختبر المسار الطبيعي فقط. جرّب مدخلاً فارغاً، وقيمة أكبر من المتوقع، وعنصراً غير موجود، وطلباً يصل من دون البيانات المطلوبة. الحالات الحدية تكشف غالباً مشكلات الفهارس والأنواع وترتيب التنفيذ. اكتب النتيجة المتوقعة قبل تشغيل الكود، ثم قارنها بالنتيجة الفعلية. إذا كان الاختبار يمر بالصدفة، أضف شرطاً أو اختباراً أوضح، ولا تكتفِ بطباعة قيمة تبدو منطقية.

تحقق من المدخلات قبل استخدامها في الحساب أو التخزين.
أعد رسالة مفهومة ورمزاً مناسباً عند وقوع الخطأ.
اجعل الاختبارات قابلة للإعادة من دون اعتماد على شبكة أو وقت متغير.
راجع أثر التغيير على الأجزاء التي تستدعي الدالة أو المكون.

ملاحظات تتعلق بجودة الكود

تظهر جودة الحل في التفاصيل الصغيرة: اسم يشرح الغرض، ودالة لا تجمع مهاماً بعيدة، ورسالة خطأ لا تترك القارئ في حيرة. لا تحاول اختصار كل سطر، فالكود المقروء أفضل من تعبير قصير يحتاج إلى شرح طويل. وفي الوقت نفسه، لا تكرر القاعدة نفسها في أماكن كثيرة؛ انقلها إلى موضع واحد عندما يكون ذلك أوضح. راجع الملف بعد أن يعمل، لأن أول نسخة تركز عادةً على الوصول إلى النتيجة أكثر من قابلية الصيانة.

احتفظ بالإعدادات التي تختلف بين جهاز وآخر خارج الكود، ولا تضع كلمات مرور أو مفاتيح خاصة في المستودع. استخدم سجلات مناسبة أثناء التطوير، ثم راجع ما ينبغي حجبه في بيئة التشغيل. إذا تعامل البرنامج مع بيانات المستخدم، فافصل بين ما يحتاجه التطبيق وما يمكن الاحتفاظ به. هذه الممارسات لا تخص لغة واحدة، بل تقلل المشكلات عندما يكبر المشروع أو يعمل عليه أكثر من شخص.

متى تعرف أن الحل يحتاج إلى تطوير؟

يحتاج المثال التعليمي إلى طبقات إضافية عندما يدخل في نظام حقيقي: قاعدة بيانات، مستخدمون متعددون، مراقبة، اختبارات، وصلاحيات. لا تضف هذه الأجزاء قبل معرفة المشكلة التي تحلها، لكن لا تنقل الكود التجريبي إلى الإنتاج كما هو. راقب حجم البيانات، وعدد الطلبات، ومصدر المدخلات، وما إذا كان الفشل يجب أن يعيد العملية أو يوقفها. اكتب قرارك في مستند صغير أو تعليق يشرح السبب، حتى لا يضطر الفريق إلى تخمينه لاحقاً.

إذا وجدت أن الخطأ يتكرر في أكثر من مكان، فابحث عن قاعدة مشتركة. وإذا أصبح التعديل في ملف صغير يؤثر في ملفات كثيرة، فراجع حدود المسؤوليات. لا توجد بنية واحدة صحيحة لكل مشروع، لكن توجد أسئلة تساعدك على اختيار بنية مناسبة: من يملك البيانات؟ من يغيرها؟ ماذا يحدث عند الفشل؟ وكيف يمكن اختبار الجزء من دون تشغيل النظام كله؟

أخطاء ينبغي تجنبها

أكثر الأخطاء شيوعاً جعل كل الحقول public، أو إنشاء getters وsetters لكل شيء حتى تختفي فائدة التغليف. لا تستخدم الوراثة لمجرد مشاركة دالة، ولا تجعل الصنف الابن يغير معنى دوال الصنف الأب. من الأفضل أحياناً تركيب Account داخل Service بدلاً من تمديده. كما ينبغي عدم رمي استثناءات عامة من دون رسالة مفهومة، وعدم وضع منطق حساس في constructor إذا كان يحتاج اتصالاً خارجياً.

خطوة تالية مناسبة

بعد هذا المثال، أنشئ واجهة PaymentMethod فيها دالة pay، ثم طبقها بوسيلتين مختلفتين. قارن بين التركيب والوراثة، واكتب اختبارات للسلوك لا لتفاصيل الحقول الخاصة. عندما يصبح التصميم واضحاً، راجع عدد الأصناف؛ كثرة الكلاسات ليست دليلاً على جودة أعلى، فالهدف أن يعكس النموذج قواعد المجال بطريقة يستطيع الفريق فهمها.

اختيار العلاقة المناسبة بين الكائنات

ليست الوراثة الخيار الافتراضي لكل تشابه بين صنفين. إذا كان الصنفان يشتركان في سلوك قابل لإعادة الاستخدام من دون علاقة منطقية واضحة، فقد يكون تركيب كائن داخل آخر أبسط وأقل ارتباطاً. اسأل: هل النوع الجديد نسخة متخصصة فعلاً من النوع القديم؟ وهل يستطيع استخدام عقده من دون شروط مفاجئة؟ إذا كانت الإجابة غير واضحة، ابدأ بواجهة صغيرة أو خدمة منفصلة. كما ينبغي أن تبقى الحقول الخاصة محمية من التعديل المباشر، وأن يمر التغيير عبر دالة تتحقق من القاعدة. الهدف من البرمجة الكائنية ليس زيادة عدد الكلاسات، بل وضع المسؤولية في مكان يمكن فهمه واختباره.

الخلاصة

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

تعديل المقال

إيفلون

البرمجة الكائنية في Java: فهم الكلاسات والوراثة والتغليف