الوراثة الفائضة (Refused Bequest)

من موسوعة حسوب
< Refactoring
مراجعة 13:44، 26 فبراير 2019 بواسطة جميل-بيلوني (نقاش | مساهمات) (مراجعة وتدقيق.)
(فرق) → مراجعة أقدم | المراجعة الحالية (فرق) | مراجعة أحدث ← (فرق)
اذهب إلى التنقل اذهب إلى البحث

توصيف المشكلة

استفادة الصنف الفرعيّ (subclass) من القليل فقط ممّا ورِثه عن الصنف الأعلى (superclass) من توابعَ (method) وحقولٍ (fields)، لتبقى التوابع الأخرى غيرَ مُستخدَمةٍ أو قد يُعاد تعريفها (redefined) مع الكثير من الاختلافات.

أسبابها

إنشاء علاقة الوراثة (inheritance) ما بين صنفين مختلفين كليًّا بدافع إعادة استخدام الشيفرة الموجودة في الصنف الأعلى (superclass) في الصنف الفرعيّ (subclass).

وما الحل؟

  • إن لم يشترك الصنف الفرعيّ (subclass) مع الصنف الأعلى (superclass) بشيءٍ، فالوراثة غير منطقيّةٍ بالأصل، والأفضلُ التخلي عنها بتبديلها إلى تفويض (delegation).
  • أمّا إن كانت علاقة الوراثة منطقيّةً فالحلُّ بالتخلُّص من حقول (fields) وتوابع (methods) الصنف الأعلى غير المستخدمة في الصنف الفرعيّ (subclass)، وذلك باستخراج كافّة الحقول والتوابع التي يحتاج إليها الصنف الفرعيّ (وليكن X) ووضعها في صنفٍ آخر جديدٍ (وليكن الصنف Y)، ثم إنشاء علاقة وراثةٍ لكلٍّ من الصنف الأعلى (وليكن Z) والفرعيّ (وهو الصنف X) من الصنف الجديد الذي أنشأته (وهو Y)، أي سيرِث الصنفان X و Z (ما يحتاجه كلاهما) من الصنف Y الذي يحتوي على الحقول والتوابع التي يحتاجها الصنف الفرعيّ من الصنف الأعلى قبل حل المشكلة. (راجع صفحة استخراج الصنف الأعلى لمزيدٍ من التفاصيل والأمثلة).

مثال

ليكن الصنف الأعلى Department والصنف الفرعيّ Employee كما هو واضحٌ بمخطَّط الأصناف الآتي:

Extract Superclass - Before.png

عند تطبيق الوراثة فإنّ الصنف الفرعيّ سيحتاج إلى التابعين getTotalAnnualCost (بعد إعادة تعريفه) وgetName ولذلك سيُنقل التابعان إلى صنف جديدٍ (باسم Party) ليصبح هذا الصنفُ الصنفَ الأعلى لكلٍّ من الصنفين Department و Employee، وبالتالي سيورِّث التابعين المشتركين إليهما، أي ستصبح الأصناف بعد حل المشكلة بالشكل:

Extract Superclass - After.png

إليك المزيد

ستحصل بعد حلِّ المشكلة على شيفرةٍ أكثر وضوحًا وتنظيمًا.

انظر أيضًا

مصادر