في الدروس السابقة، تعرفنا على كيفية تغليف البيانات والسلوك داخل الفئات (Classes) وكيفية التعامل مع الكائنات (Objects). اليوم سننتقل إلى مستوى أعلى من تجريد البرمجة الكائنية التوجه (OOP)، حيث سنتعلم كيف نجعل الكود الخاص بنا أكثر قابلية لإعادة الاستخدام وأكثر مرونة من خلال مفهومين أساسيين: الوراثة (Inheritance) وتعدد الأشكال (Polymorphism).

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

مفهوم الوراثة: بناء علاقات النوع في بايثون

تسمح لنا الوراثة بإنشاء فئة جديدة بناءً على فئة موجودة بالفعل. الفئة الجديدة التي نسميها الفئة الابنة (Child Class) ترث السمات والأساليب (Methods) من الفئة الأب (Parent Class). الهدف ليس مجرد نسخ الكود، بل إنشاء علاقة منطقية تسمى علاقة "is-a" (أي أن الابن هو نوع من الأب).

تخيل أنك تبني نظامًا لإدارة موظفي شركة. بدلاً من إعادة تعريف الخصائص الأساسية مثل الاسم والرقم الوظيفي في كل فئة، ننشئ فئة أساسية (Base Class) ونبني عليها التخصصات المختلفة.

class Employee:
    def __init__(self, name, emp_id):
        self.name = name
        self.emp_id = emp_id

    def get_details(self):
        return f"Name: {self.name}, ID: {self.emp_id}"

class Developer(Employee):
    def __init__(self, name, emp_id, language):
        super().__init__(name, emp_id)
        self.language = language

    def get_details(self):
        base_info = super().get_details()
        return f"{base_info}, Language: {self.language}"

dev = Developer("Ahmed", "S101", "Python")
print(dev.get_details())

في هذا المثال، استخدمنا الدالة super()، وهي وسيلة بايثون القياسية للوصول إلى أعضاء الفئة الأب بأمان. لاحظ كيف قمنا بتجاوز (Override) الطريقة get_details؛ أي أننا أعدنا تعريفها داخل الفئة الابنة لتقدم تفاصيل إضافية خاصة بالمطور، بينما استفدنا في نفس الوقت من البنية الأساسية التي وفرتها الفئة الأب دون الحاجة لإعادة كتابتها.

تعدد الأشكال (Polymorphism): واجهة واحدة، سلوكيات متعددة

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

لنفترض أن لدينا نظام رسم هندسي يحتوي على أشكال مختلفة، وكل شكل يجب أن يُحسب مساحته بطريقة مختلفة تمامًا بناءً على معادلته الرياضية:

class Shape:
    def area(self):
        pass

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius

    def area(self):
        return 3.14 * self.radius ** 2

class Square(Shape):
    def __init__(self, side):
        self.side = side

    def area(self):
        return self.side * self.side

shapes = [Circle(5), Square(4)]

for shape in shapes:
    print(f"Area: {shape.area()}")

هنا، الدالة area تعمل بشكل مختلف تماماً بناءً على نوع الكائن الموجود داخل القائمة، ولكن الحلقة التكرارية لا تهتم بنوع الشكل الهندسي، فهي فقط تستدعي الطريقة area() بشكل موحد. هذا هو الجوهر العملي لتعدد الأشكال: الانفصال التام بين من يطلب التنفيذ ومن ينفذه.

متى نستخدم الوراثة ومتى نتجنبها؟

الخطأ الشائع لدى المبرمجين المبتدئين هو محاولة استخدام الوراثة في كل مكان لحل مشاكل هيكلة الكود. الوراثة تخلق ما يسمى بـ الاقتران القوي (Tight Coupling) بين الفئات؛ أي أن أي تغيير جذري في الفئة الأب سيؤثر حتماً على جميع الفئات الابنة المرتبطة بها.

للحفاظ على مرونة النظام البرمجي، إليك بعض القواعد الإرشادية الهامة:

• استخدم الوراثة فقط إذا كانت هناك علاقة "هو نوع من" (is-a) واضحة ومستقرة على المدى الطويل.
• إذا كانت العلاقة بين الكائنات هي "يحتوي على" (has-a)، ففكر فوراً في استخدام مفهوم التكوين (Composition) بدلاً من الوراثة المباشرة.
• لا تحاول وراثة خصائص أو وظائف لمجرد تقليل عدد أسطر الكود إذا كانت العلاقة المنطقية بين الفئتين ضعيفة أو غير مبررة.

أخطاء شائعة في التعامل مع الوراثة وتجاوز الطرق

عند بناء أنظمة تعتمد على البرمجة الكائنية، يقع المبرمجون في بعض الأخطاء المتكررة التي تؤدي إلى صعوبة تتبع الأخطاء البرمجية:

1. نسيان استدعاء الدالة super(): عند تجاوز دالة التهيئة __init__ في الفئة الابنة، يجب دائماً استدعاء الفئة الأب باستخدام super().__init__()، وإلا فلن يتم تهيئة الخصائص الأساسية للفئة الأب، مما يؤدي إلى ظهور أخطاء عند محاولة الوصول لتلك المتغيرات.
2. التعمق الزائد في شجرة الوراثة: إنشاء تسلسل طويل ومعقد من الفئات (مثل جد ثم أب ثم ابن ثم حفيد) يجعل الكود صعب القراءة والتحليل والصيانة. إذا وجدت نفسك تتجاوز ثلاثة مستويات من الوراثة، فربما حان الوقت لإعادة تصميم هيكلية البرنامج بالكامل.
3. كسر مبدأ استبدال لى سكو (Liskov Substitution Principle): ينص هذا المبدأ على أن الكائنات من الفئة الابنة يجب أن تكون قابلة للاستبدال بالكائنات من الفئة الأب دون التأثير على صحة أو سلوك البرنامج. إذا اضطررت لاستخدام isinstance() للتحقق من نوع الكائن داخل الدوال، فهذا غالباً مؤشر على وجود خلل في تصميم الوراثة لديك.

التطبيق العملي: الوراثة المتعددة في بايثون وترتيب حل الطرق

تتميز لغة بايثون بدعمها للوراثة المتعددة (Multiple Inheritance)، حيث يمكن لفئة واحدة أن ترث الخصائص والأساليب من أكثر من فئة أب في نفس الوقت. ورغم القوة الكبيرة التي تمنحها هذه الميزة للمبرمج، إلا أنها قد تؤدي أحيانًا إلى تعقيد في ما يُعرف بـ ترتيب حل الطريقة (Method Resolution Order - MRO).

تأمل المثال العملي التالي لنظام يجمع بين خصائص الطباعة والمسح الضوئي:

class Printer:
    def print_doc(self):
        return "Printing document..."

class Scanner:
    def scan_doc(self):
        return "Scanning document..."

class AllInOne(Printer, Scanner):
    pass

device = AllInOne()
print(device.print_doc())
print(device.scan_doc())

في هذا المثال، ورثت الفئة AllInOne ميزات كل من Printer و Scanner في آنٍ واحد. لمعالجة تعارض الأسماء المحتمل وتحديد تسلسل البحث، تعتمد بايثون على خوارزمية تسمى C3 Linearization لتحديد الترتيب الذي يتم البحث فيه عن الدوال. يمكنك دائماً التحقق من هذا الترتيب لأي فئة متقدمة باستخدام السمة المدمجة __mro__ عبر طباعة الأمر مثل print(AllInOne.__mro__).

الخلاصة والتوجيهات الاحترافية

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

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