الوراثة الفائضة (Refused Bequest)
توصيف المشكلة
استفادة الصنف الفرعيّ (subclass) من القليل فقط ممّا ورِثه عن الصنف الأعلى (superclass) من توابعَ (method) وحقولٍ (fields)، لتبقى التوابع الأخرى غيرَ مُستخدَمةٍ أو قد يُعاد تعريفها (redefined) مع الكثير من الاختلافات.
أسبابها
إنشاء علاقة الوراثة (inheritance) ما بين صنفين مختلفين كليًّا بدافع إعادة استخدام الشيفرة الموجودة في الصنف الأعلى (superclass) في الصنف الفرعيّ (subclass).
وما الحل؟
- إن لم يشترك الصنف الفرعيّ (subclass) مع الصنف الأعلى (superclass) بشيءٍ، فالوراثة غير منطقيّةٍ بالأصل، والأفضلُ التخلي عنها بتبديلها إلى تفويض (delegation).
- أمّا إن كانت علاقة الوراثة منطقيّةً فالحلُّ بالتخلُّص من حقول (fields) وتوابع (methods) الصنف الأعلى غير المستخدمة في الصنف الفرعيّ (subclass)، وذلك باستخراج كافّة الحقول والتوابع التي يحتاج إليها الصنف الفرعيّ (وليكن X) ووضعها في صنفٍ آخر جديدٍ (وليكن الصنف Y)، ثم إنشاء علاقة وراثةٍ لكلٍّ من الصنف الأعلى (وليكن Z) والفرعيّ (وهو الصنف X) من الصنف الجديد الذي أنشأته (وهو Y)، أي سيرِث الصنفان X و Z (ما يحتاجه كلاهما) من الصنف Y الذي يحتوي على الحقول والتوابع التي يحتاجها الصنف الفرعيّ من الصنف الأعلى قبل حل المشكلة. (راجع صفحة استخراج الصنف الأعلى لمزيدٍ من التفاصيل والأمثلة).
مثال
ليكن الصنف الأعلى Department والصنف الفرعيّ Employee كما هو واضحٌ بمخطَّط الأصناف الآتي:
عند تطبيق الوراثة فإنّ الصنف الفرعيّ سيحتاج إلى التابعين getTotalAnnualCost (بعد إعادة تعريفه) وgetName ولذلك سيُنقل التابعان إلى صنف جديدٍ (باسم Party) ليصبح هذا الصنفُ الصنفَ الأعلى لكلٍّ من الصنفين Department و Employee، وبالتالي سيورِّث التابعين المشتركين إليهما، أي ستصبح الأصناف بعد حل المشكلة بالشكل:
إليك المزيد
ستحصل بعد حلِّ المشكلة على شيفرةٍ أكثر وضوحًا وتنظيمًا.