الفرق بين المراجعتين ل"Refactoring/replace delegation with inheritance"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: استبدال التفويض بالتوريث (Replace Delegation with Inheritance)}}</noinclude> == المشكلة == يحتوي الصنف...')
 
ط (مراجعة وتدقيق.)
 
سطر 9: سطر 9:
  
 
==== قبل إعادة التصميم ====
 
==== قبل إعادة التصميم ====
[[ملف:Replace Delegation with Inheritance - Before.png|بديل=يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.|بدون|تصغير|يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.]]
+
التابع الموجود في الصنف <code>Employee</code> مفوَّض إلى التابع <code>()getName</code> في الصنف <code>Person</code>:[[ملف:Replace Delegation with Inheritance - Before.png|بديل=يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.|بدون|تصغير|يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.]]
  
 
==== بعد إعادة التصميم ====
 
==== بعد إعادة التصميم ====
[[ملف:Replace Delegation with Inheritance - After.png|بديل=أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.|بدون|تصغير|أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.]]
+
جعل الصنف <code>Employee</code> يرث من الصنف <code>Person</code> والتخلص من التفويض:[[ملف:Replace Delegation with Inheritance - After.png|بديل=أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.|بدون|تصغير|أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.]]
  
 
== لم إعادة التصميم؟ ==
 
== لم إعادة التصميم؟ ==
يُعد التفويض نهج أكثر مرونة من التوريث، لأنه يسمح بتغيير طريقة تنفيذ التفويض ووضع أصناف أخرى هناك أيضًا. ومع ذلك، لا يصبح التفويض مفيدًا إذا فوضت الإجراءات إلى صنفٍ واحد فقط وجميع توابعه العامة.
+
يُعد التفويض نهجًا أكثر مرونة من التوريث، لأنَّه يسمح بتغيير طريقة تنفيذ التفويض ووضع أصناف أخرى هناك أيضًا. ومع ذلك، لا يصبح التفويض مفيدًا إذا فوضت الإجراءات إلى صنفٍ واحد فقط وجميع توابعه العامة.
  
 
في مثل هذه الحالة، إذا استبدلت التفويض بالتوريث، تُطهِّر الصنف من عدد كبير من توابع التفويض وتعفي نفسك من الحاجة لإنشاءها لكل تابع صنف مفوَّض جديد.
 
في مثل هذه الحالة، إذا استبدلت التفويض بالتوريث، تُطهِّر الصنف من عدد كبير من توابع التفويض وتعفي نفسك من الحاجة لإنشاءها لكل تابع صنف مفوَّض جديد.
  
 
== فوائد تطبيق الحل ==
 
== فوائد تطبيق الحل ==
* تقليل طول الشيفرة. عدم الحاجة لجميع توابع التفويض هذه.
+
* تقليل طول الشيفرة، إذ لم نعد بحاجة لجميع توابع التفويض هذه.
  
=== متى يُترك هذا الحل؟ ===
+
== متى يترك هذا الحل؟ ==
* لا تستخدم هذه التقنية إذا كان الصنف يحتوي على تفويض لجزء فقط من التوابع العامة لصنف المفوَّض. بفعل هذا، ستنتهك مبدأ ليسكوف للتعويض.
+
* لا تستخدم هذه التقنية إذا كان الصنف يحتوي على تفويض لجزء فقط من التوابع العامة لصنف المفوَّض. بفعل هذا، ستنتهك [[wikipedia:Liskov_substitution_principle|مبدأ ليسكوف للتعويض]].
 
* لا يمكن استخدام هذه التقنية إلا إذا كان الصنف لا يزال بدون أصل.
 
* لا يمكن استخدام هذه التقنية إلا إذا كان الصنف لا يزال بدون أصل.
  
 
== آلية الحل ==
 
== آلية الحل ==
# اجعل الصنف صنفٍ فرعي من الصنف المفوَّض.
+
# اجعل الصنف صنفًا فرعيًّا من الصنف المفوَّض.
 
# ضع الكائن الحالي في حقل يحتوي على مرجع إلى الكائن المفوَّض.
 
# ضع الكائن الحالي في حقل يحتوي على مرجع إلى الكائن المفوَّض.
 
# احذف التوابع التي لها تفويض بسيط واحدًا تلو الآخر. إذا كانت أسمائهم مختلفة، استخدم [[Refactoring/rename method|إعادة تسمية التابع]] لإعطاء كل التوابع اسمًا واحد.
 
# احذف التوابع التي لها تفويض بسيط واحدًا تلو الآخر. إذا كانت أسمائهم مختلفة، استخدم [[Refactoring/rename method|إعادة تسمية التابع]] لإعطاء كل التوابع اسمًا واحد.
 
# استبدل جميع المراجع إلى الحقل المفوَّض بمراجع إلى الكائن الحالي.
 
# استبدل جميع المراجع إلى الحقل المفوَّض بمراجع إلى الكائن الحالي.
# أزل حقل المفوَّض.
+
# أزل الحقل المفوَّض.
  
 
== انظر أيضًا ==
 
== انظر أيضًا ==
سطر 42: سطر 42:
 
[[تصنيف:Refactoring]]
 
[[تصنيف:Refactoring]]
 
[[تصنيف:Refactoring Techniques]]
 
[[تصنيف:Refactoring Techniques]]
[[تصنيف:Dealing with Generalization]]
+
[[تصنيف:Refactoring Dealing with Generalization]]

المراجعة الحالية بتاريخ 11:28، 26 فبراير 2019

المشكلة

يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.

الحل

جعل الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.

مثال

قبل إعادة التصميم

التابع الموجود في الصنف Employee مفوَّض إلى التابع ()getName في الصنف Person:

يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.
يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.

بعد إعادة التصميم

جعل الصنف Employee يرث من الصنف Person والتخلص من التفويض:

أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.
أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.

لم إعادة التصميم؟

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

في مثل هذه الحالة، إذا استبدلت التفويض بالتوريث، تُطهِّر الصنف من عدد كبير من توابع التفويض وتعفي نفسك من الحاجة لإنشاءها لكل تابع صنف مفوَّض جديد.

فوائد تطبيق الحل

  • تقليل طول الشيفرة، إذ لم نعد بحاجة لجميع توابع التفويض هذه.

متى يترك هذا الحل؟

  • لا تستخدم هذه التقنية إذا كان الصنف يحتوي على تفويض لجزء فقط من التوابع العامة لصنف المفوَّض. بفعل هذا، ستنتهك مبدأ ليسكوف للتعويض.
  • لا يمكن استخدام هذه التقنية إلا إذا كان الصنف لا يزال بدون أصل.

آلية الحل

  1. اجعل الصنف صنفًا فرعيًّا من الصنف المفوَّض.
  2. ضع الكائن الحالي في حقل يحتوي على مرجع إلى الكائن المفوَّض.
  3. احذف التوابع التي لها تفويض بسيط واحدًا تلو الآخر. إذا كانت أسمائهم مختلفة، استخدم إعادة تسمية التابع لإعطاء كل التوابع اسمًا واحد.
  4. استبدل جميع المراجع إلى الحقل المفوَّض بمراجع إلى الكائن الحالي.
  5. أزل الحقل المفوَّض.

انظر أيضًا

مصادر