نتائج البحث

المشكلة تؤدي إعادة بعض التوابع للقيمة null بدلًا من الكائنات الحقيقية إلى امتلاء الشيفرة البرمجية بالعديد من نقاط التحقق من القيمة null. الحل إعادة كائن فارغ يظهر السلوك الافتراضي بدلًا من null. مثال قبل إعادة التصميم وجودة نقطة تحقق شرطية من الكائن customer لاتخاذ إجراء مناسب إن كانت قيمته null: في لغة Java: if (customer == null) { plan = BillingPlan.basic(); } else { plan = customer.getPlan(); } في لغة C#‎: if (customer == null) { plan = BillingPlan.Basic(); } else { ...

توصيف المشكلة وجود الكثير من التعليقات في التوابع (methods) بهدف الشرح التفصيليّ للشيفرة. أسبابها غالبًا ما يكون السبب منطقيًّا لإضافة التعليقات وخاصّة عندما تكون الشيفرة مبهمةً غير واضحة، لكن بهذه الحالة لن نعدَّ تلك التعليقات إلا محاولاتٍ بائسةً لتغطية الشيفرة الرديئة بجانبها! ولتكن القاعدة: إنّ أفضل تعليقٍ يمكن أن تضيفه هو تسمية التوابع (methods) والأصناف (classes) تسميةً جيّدةً معبِّرة. وإذا ما وجدتَ أن الشيفرة لن تكون واضحةً بحذف التعليقات المُضافة، فمن المُؤسف القول بضرورة تغيير بُنيتها (structure) إلى الشكل الذي ...

المشكلة لديك متغيرات منطقية تعمل كرايات تحكم لتعبيرات منطقية متعددة. الحل استخدم الكلمات المفتاحية break و continue و return بدلًا من هذه المتغيرات. لم إعادة التصميم؟ تعود رايات التحكم إلى الأيام الخوالي، عندما كان يُتاح دائمًا للمبرمج "الأصيل" نقطة إدخال واحدة للدوال (سطر تعريف الدالة) ونقطة خروج واحدة (في نهاية الدالة). لكن هذا النمط المتشدد عفا عليه الزمن في لغات البرمجة الحديثة، إذ أصبح لدينا عوامل خاصة لتعديل تدفق التحكم في الحلقات وغيرها من التركيبات المُعقدة مثل: break: إيقاف الحلقة. continue: ...

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

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

المشكلة يكون تعيين قيمة الحقل فقط عند إنشائه، ولا تتغير في أي وقت لاحق. الحل إزالة التوابع التي تضبط قيمة الحقل. مثال قبل إعادة التصميم يضبط التابع ()setImmutableValue قيمةً غير قابلة للتغيير أو التعديل في المستقبل: يغيّر التابع من قيمة الحقل. بعد إعادة التصميم حذف التابع ()setImmutableValue من الصنف Customer: إزالة التابع الذي يضبط قيمة الحقل. لم إعادة التصميم؟ إذا كنت تريد منع أي تغييرات في قيمة الحقل. آلية الحل يجب أن تكون قيمة الحقل قابلة للتغيير فقط في الباني. ...

المشكلة هل بيانات النطاق المخزَّنة في أصناف هي المسؤولة عن واجهة المستخدم الرسومية (GUI)؟ إذًا، إليك الحل. الحل فصل البيانات في أصناف منفصلة لضمان الاتصال والتزامن بين صنف النطاق وواجهة المستخدم الرسومية (GUI). مثال قبل إعادة التصميم إليك المخطط التالي لبيانات نطاق مخزَّنة في أصناف والمسؤولة عن الواجهة الرسومية: بيانات النطاق مخزَّنة في أصناف. بعد إعادة التصميم يصبح المخطط السابق بالشكل التالي بعد إعادة التصميم: فصل البيانات في أصناف منفصلة لضمان الاتصال والتزامن بين صنف النطاق وواجهة المستخدم الرسومية. لم ...

المشكلة لا يُستخدم معاملٌ ما في متن التابع. الحل إزالة المعامل غير المستخدم. مثال قبل إعادة التصميم تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه. تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه. بعد إعادة التصميم إزالة المعامل Date من التابع ()getContact لعدم استخدامه: إزالة المعامل Date من التابع ()getContact. لم إعادة التصميم؟ يفرض كل معامل موجود في استدعاء التوابع على المبرمج أن يقرأه لمعرفة ما هي المعلومات الموجودة في هذا المعامل. وإذا كان المعامل غير مستخدم على ...

المشكلة تؤدي توابع متعددة أعمالًا مماثلة تختلف فقط من حيث قيمها الداخلية أو أرقامها أو عملياتها. الحل تجميع هذه التوابع باستخدام معامل يُمرر القيمة الخاصة الضرورية. مثال قبل إعادة التصميم يؤدي التابعان ()fivePercentRaise و ()tenPercentRaise الغرض ذاته باختلاف النسبة المئوية المراد زيادتها للموظف Employee: يؤدي التابعان أعمالًا مماثلة تختلف فقط من حيث قيمها الداخلية أو أرقامها أو عملياتها. بعد إعادة التصميم تجميع التابعان السابقان في تابع واحد يدعى ()raise مع تمرير النسبة المئوية المتغيرة إليه: يجمع التابعين باستخدام معامل يُمرر ...

وهي الأجزاء عديمة النفع في الشيفرة، وسيجعلُ التخلُّصُ منها الشيفرةَ نظيفةً يسيرة الفهم وأكثر فعاليّة، منها: التعليقات (comments) المشكلة: وجود الكثير من التعليقات في التوابع (methods) بهدف الشرح التفصيليّ للشيفرة. الحل: يكون الحل بناءً على الحالة المستعملة وهو: تقسيم التعبير الواحد إلى تعابيرَ فرعيّة (subexpressions) بالاعتماد على استخراج المتغيِّرات، أو عزل ذلك المقطع في تابعٍ (method) جديدٍ باسمٍ معبِّر، أو إعادة تسمية التابع (rename method) لاسمٍ يشرح ذاته بذاته، أو إضافة التأكيدات. تكرار  الشيفرة (duplicates) المشكلة: التشابه (أو التطابق المطلق) بين مقطعين من الشيفرة ...

توصيف المشكلة يتطلَّب إنشاءُ صنفٍ فرعيٍّ (subclass) لأحد الأصناف إنشاءَ صنفٍ فرعيٍّ ثانٍ لصنفٍ آخر غيره. أسبابها لا تبدو المشكلة واضحةً في الهيكليّات (hierarchies) الصغيرة، ولكنها تبدأ بالظهور مع إضافة أصناف (classes) جديدةٍ ممّا يجعل إجراء التعديلات أمرًا صعبًا. وما الحل؟ التخلُّص من التكرار التفرعيّ بين الهيكليّتين (hierarchies)، ويتمّ بخطوتين: إنشاء مرجعيّة (reference) من إحدى الهيكليّتين التفرعيّتين إلى الهيكليّة الثانية. إزالة الهيكليّة في الصنف المُشار إليه (referred class)، وذلك بنقل التوابع (move methods) ونقل الحقول (move fields). إليك المزيد ستحصل ...

المشكلة لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات. الحل إنشاء معامل جديد لتمرير البيانات الضرورية. مثال قبل إعادة التصميم لا يملك التابع ()getContact في الصنف Customer لجدولة موعدٍ للتواصل مع الزبون: لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات. بعد إعادة التصميم أصبح بالإمكان تمرير تاريخ إلى التابع ()getContact لتصبح بيانات جدولة تاريخ مناسب مع الزبون مكتملة: إنشاء معامل جديد لتمرير البيانات الضرورية. لم إعادة التصميم؟ تحتاج إلى إجراء بعض تغييرات على أحد التوابع، وتتطلب هذه التغييرات إضافة معلومات ...

المشكلة شيفرة برمجية متطابقة موجودة في جميع فروع الشَرطيات. الحل نقل الشيفرة البرمجية خارج الشَرطية. مثال قبل إعادة التصميم استدعاء وتنفيذ الدالة ()send في نهاية جميع فروع الكتلة if الشرطية سواءً أكان الشرط محققًا أم لا: في لغة Java: if (isSpecialDeal()) { total = price * 0.95; send(); } else { total = price * 0.98; send(); } في لغة C#‎: if (IsSpecialDeal()) { total = price * 0.95; Send(); } else { total = price * 0.98; ...

توصيف المشكلة وجود العديد من أصناف البيانات في الشيفرة، والتي تُستخدَم لتخزين البيانات التي تحتاج إليها الأصناف الأخرى، إذ تحتوي على حقولٍ للبيانات (fields) وتوابع للوصول إليها (accessors) أي توابعَ للحصول على بيانات الحقول (getter) وأخرى لتعديلها (setter)، ولا تقوم هذه الأصناف بأيّ مهمّة أخرى ولا تستطيع كذلك تنفيذ العمليات (operations) على بياناتها بمفردها. أسبابها من الطبيعي أن يحتوي الصنف -بادئ الأمر- على القليل من الحقول العامّة (public fields) وبعض التوابع للوصول إليها (accessors) ولكن إن استمرَّ الصنف كذلك فلن ...

توصيف المشكلة التطابق بالمهام (function) ما بين صنفين (classes) ولكن بأسماءٍ مختلفةٍ لتوابعهما (methods). أسبابها عدم دراية المبرمج بوجود صنفٍ آخر يكافِئ بمهامّه مهامّ الصنف الحالي الذي ينشِئه. وما الحل؟ حذف أحد الصنفين بعد تنفيذ إحدى الحلول الآتية: إعادة تسمية التوابع (methods) لتصبح متطابقةً بكافّة الأصناف البديلة (alternative) (أي الأصناف المتكافئة بالمهام). توحيد التوقيع (signature) وتعريف الاستخدام ما بين التوابع، وذلك إمّا بنقل التابع (move method) أو إضافة المعاملات (add parameters) أو دمج التوابع عبر المعاملات (parameterize method). إن كان ...

توصيف المشكلة التشابه (أو التطابق المطلق) بين مقطعين من الشيفرة في البرنامج. أسبابها تحدث هذه المشكلة عندما يعمل أكثرُ من مبرمجٍ على كتابة أجزاءَ مختلفةٍ من نفس البرنامج وبنفس الوقت، فلا يدري أحدهم أنّ الشيفرة التي يكتبها قد سبقه بها مبرمجٌ آخر ومن الممكن استخدامها نفسها دون الحاجة لتكرارها. أو قد تنتُج عن وجود جزئين من الشيفرة مختلفين شكليًّا متماثلين ضمنيًا (يؤديان نفس المهمة)، ومن الصعب كشف هذا النوع من التكرار وعلاجه. قد يكون التكرار هادفًا ببعض الأحيان، كأن يكون ...

قد يزداد حجم الشيفرات والتوابع (methods) والأصناف (classes) ازديادًا كبيرًا ليصل لمرحلةٍ يصعُب التعامل معها، ولا يحدث هذا بشكلٍ فجائيِّ دفعةً واحدةً، بل يكون ناتجًا عن تراكم الإضافات أثناء تطوير البرنامج (وخاصةً عندما لا يبذل أحدٌ جهدًا للحدِّ من ذلك التشعب)، ويبدو هذا التضخم واضحًا. التوابع الطويلة (long methods) المشكلة: تنتُج عن احتواء شيفرة التابع على الكثير من الأسطر. الحل: يشمل: إنشاء توابعَ جديدةٍ، أو تبديل المتغيَّرات المؤقَّتة إلى استداعاءات للدوال أو الاعتماد على كائن المعاملات، أو التعامل مع الكائن ككُلٍّ، أو ...

المشكلة يستخدم العديد من العملاء نفس الجزء من واجهة الصنف. حالة أخرى: عندما يوجد نفس الجزء من الواجهة في صنفين. الحل نقل هذا الجزء المتطابق إلى الواجهة الخاصة به. مثال قبل إعادة التصميم استخدام التابعين ()getRate و ()hasSpecialSkill في الصنف Employee بكثرة: يستخدم العديد من العملاء نفس الجزء من واجهة الصنف. بعد إعادة التصميم استخراج هذين التابعين إلى واجهة خاصة بهما تدعى Billable: تقل هذا الجزء المتطابق إلى الواجهة الخاصة به. لم إعادة التصميم؟ تكون الواجهات مناسبة جدًا عندما تلعب ...

المشكلة يصل العميل (client) إلى كائنٍ (object) ما وليكن الكائن B من أحد حقول (fields) أو توابع (methods) كائنٍ آخر وليكن A، ومن ثمّ يستدعي تابعًا لهذا الكائن B. الحل إنشاء تابعٍ جديدٍ في الصنف A والذي يُفضي إلى استدعاءٍ للكائن B، وبهذا لن يعلم العميل تفاصيل التفويض (delegation) للكائن B ولن يعتمد على ذلك. مثال قبل إعادة التصميم يتعامل صنف العميل (client class) مع صنفين، الأول صنف الأقسام (Department) والثاني صنف الأشخاص (Person) واللذان يحتويان تابعين للحصول على كائنٍ ...

المشكلة وجود عدة شروط تؤدي إلى نفس النتيجة أو الإجراء. الحل توحيد جميع هذه الشروط في تعبير وحيد. مثال قبل إعادة التصميم وجود عدة شروط يتم التحقق منها في الشيفرة: في لغة Java: double disabilityAmount() { if (seniority < 2) { return 0; } if (monthsDisabled > 12) { return 0; } if (isPartTime) { return 0; } // حساب مقدار العجز //... } في ...