الفرق بين المراجعتين لصفحة: «Refactoring/switch statements»
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:استخدام التعليمة Switch}}</noinclude> == توصيف المشكلة == وجود تركيبٍ معقَّدٍ لتعليمة <code>...' |
جميل-بيلوني (نقاش | مساهمات) ط مراجعة وتدقيق. |
||
سطر 32: | سطر 32: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Smells]] | [[تصنيف:Refactoring Smells]] | ||
[[تصنيف:Refactoring | [[تصنيف:Refactoring Object-Orientation Abusers]] |
المراجعة الحالية بتاريخ 13:43، 26 فبراير 2019
توصيف المشكلة
وجود تركيبٍ معقَّدٍ لتعليمة switch
أو عدّة تعليمات if
متسلسلة.
أسبابها
ما يميِّز البرمجة كائنيّة التوجّه (OO) هو اعتمادها النادر على المعاملين switch
و case
، إذ تُوزَّع شيفرة switch
بمواقع مختلفة من البرنامج بدلًا من تجمعيها في تعليمة switch
واحدةٍ، وعند إضافة شرطٍ جديدٍ عليك إيجاد كافّة شيفرات switch
لتعديلها، وكقاعدة عامّة: وجود تعليمة switch
يعني أن عليك البدء بالتفكير بمبدأ التعدديّة الشكليّة (polymorphism).
وما الحل؟
- عزل تعليمة
switch
ووضعها بالصنف الصحيح عبر إنشاء صنفٍ (class) ونقل التابع (method) إليه. - عند اعتماد تعليمة
switch
على شيفرة النوع (type code) (كما هو الحال عند تفعيل نمط تشغيل البرنامج [program's runtime])، فالحلُّ بتبديل شيفرة النوع إلى صنف فرعيّ (subclass) أو تبديل شيفرة النوع إلى حالة/استراتيجيّة (state/strategy). - يجب تبديل التعليمات الشرطيّة (conditionals) إلى التعدّدية الشكليّة (polymorphism) بعد تحديد بُنية الوراثة (inheritance structure).
- ولكنّ تطبيق التعدّدية الشكليّة سيكون بلا جدوى عند وجود الكثير من الشروط في تعليمة
switch
والتي تحتوي على استدعاءات مُتكرِّرة لنفس التابع (method) مع اختلاف المعاملات (parameters) فيما بينها، إذ من الأفضل بمثل هذه الحالة تقسيم التابع إلى توابع أصغر وذلك بتبديل المعاملات إلى توابع صريحة (explicit methods) وتعديل تعليمةswitch
وفقًا لهذا التبديل. - إن كان لأحد الخيارات الشرطيّة القيمة
null
فالحلُّ بإنشاء كائن null (null object).
إليك المزيد
ستحصل بحلِّ المشكلة على شيفرة أكثر تنظيمًا.
تجاهل المشكلة
- عند استخدام تعليمة
switch
لتنفيذ مهامِّ بسيطةٍ جدًا في فروعها، فلا داعي حينئذٍ لأيّ من التغييرات بالشيفرة. - تًستخدم تعليمة
switch
غالبًا في نمط التصميم المُنتِج (Factory design pattern) وعندها لا يُعدُّ وجودها بالشيفرة مشكلةً ومن الممكن تجاهلها، وللمزيد من التفاصيل راجع التوابع المُنتجة (Factory methods) أو المُنتِج المُجرَّد (abstract Factory) لاختيار الصنف المُنشَأ.
انظر أيضًا
- استخراج الأصناف (extract class)
- تبديل شيفرة النوع إلى صنف فرعيّ (subclass)
- تبديل شيفرة النوع إلى حالة/استراتيجيّة (state/strategy).
- تبديل التعليمات الشرطيّة (conditionals) إلى التعدّدية الشكليّة (polymorphism)
- تبديل المعاملات إلى توابع صريحة (explicit methods)
- إنشاء كائن null (null object).