عرض مصدر Refactoring/switch statements

<noinclude>{{DISPLAYTITLE:استخدام التعليمة Switch}}</noinclude>
== توصيف المشكلة ==
وجود تركيبٍ معقَّدٍ لتعليمة <code>switch</code> أو عدّة تعليمات <code>if</code> متسلسلة.

== أسبابها ==
ما يميِّز البرمجة كائنيّة التوجّه (OO) هو اعتمادها النادر على المعاملين <code>switch</code> و <code>case</code>، إذ تُوزَّع شيفرة <code>switch</code> بمواقع مختلفة من البرنامج بدلًا من تجمعيها في تعليمة <code>switch</code> واحدةٍ، وعند إضافة شرطٍ جديدٍ عليك إيجاد كافّة شيفرات <code>switch</code> لتعديلها، وكقاعدة عامّة: وجود تعليمة <code>switch</code> يعني أن عليك البدء بالتفكير بمبدأ التعدديّة الشكليّة (polymorphism).

== وما الحل؟ ==
* عزل تعليمة <code>switch</code> ووضعها بالصنف الصحيح عبر [[Refactoring/extract class|إنشاء صنفٍ (class)]] ونقل التابع (method) إليه.
* عند اعتماد تعليمة <code>switch</code> على شيفرة النوع (type code) (كما هو الحال عند تفعيل نمط تشغيل البرنامج [program's runtime])، فالحلُّ [[Refactoring/replace type code with subclasses|بتبديل شيفرة النوع إلى صنف فرعيّ (subclass)]] أو [[Refactoring/replace type code with state strategy|تبديل شيفرة النوع إلى حالة/استراتيجيّة (state/strategy)]]. 
* يجب [[Refactoring/replace conditional with polymorphism|تبديل التعليمات الشرطيّة (conditionals) إلى التعدّدية الشكليّة (polymorphism)]] بعد تحديد بُنية الوراثة (inheritance structure).
* ولكنّ تطبيق التعدّدية الشكليّة سيكون بلا جدوى عند وجود الكثير من الشروط في تعليمة <code>switch</code> والتي تحتوي على استدعاءات مُتكرِّرة لنفس التابع (method) مع اختلاف المعاملات (parameters) فيما بينها، إذ من الأفضل بمثل هذه الحالة تقسيم التابع إلى توابع أصغر وذلك [[Refactoring/replace parameter with explicit methods|بتبديل المعاملات إلى توابع صريحة (explicit methods)]] وتعديل تعليمة <code>switch</code> وفقًا لهذا التبديل.
* إن كان لأحد الخيارات الشرطيّة القيمة <code>null</code> فالحلُّ [[Refactoring/introduce null object|بإنشاء كائن null‏ (null object)]].

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

== تجاهل المشكلة ==
* عند استخدام تعليمة <code>switch</code> لتنفيذ مهامِّ بسيطةٍ جدًا في فروعها، فلا داعي حينئذٍ لأيّ من التغييرات بالشيفرة.
* تًستخدم تعليمة <code>switch</code> غالبًا في نمط التصميم المُنتِج (Factory design pattern) وعندها لا يُعدُّ وجودها بالشيفرة مشكلةً ومن الممكن تجاهلها، وللمزيد من التفاصيل راجع التوابع المُنتجة (Factory methods) أو المُنتِج المُجرَّد (abstract Factory) لاختيار الصنف المُنشَأ.

== انظر أيضًا ==
* [[Refactoring/extract class|استخراج الأصناف (extract class)]]
* [[Refactoring/replace type code with subclasses|تبديل شيفرة النوع إلى صنف فرعيّ (subclass)]]
* [[Refactoring/replace type code with state strategy|تبديل شيفرة النوع إلى حالة/استراتيجيّة (state/strategy)]].
* [[Refactoring/replace conditional with polymorphism|تبديل التعليمات الشرطيّة (conditionals) إلى التعدّدية الشكليّة (polymorphism)]] 
* [[Refactoring/replace parameter with explicit methods|تبديل المعاملات إلى توابع صريحة (explicit methods)]]
* [[Refactoring/introduce null object|إنشاء كائن null‏ (null object)]].

== مصادر ==
* [https://refactoring.guru/smells/switch-statements صفحة توثيق استخدام تعليمة <code>switch</code> في موقع refactoring.guru.] 
[[تصنيف:Refactoring]]
[[تصنيف:Refactoring Smells]]
[[تصنيف:Refactoring Object-Orientation Abusers]]