نتائج البحث

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

تقنية إعادة التصميم هذه هي حالة خاصة من تبديل قيم البيانات إلى كائنات. المشكلة لديك مصفوفة تحتوي على أنواع مختلفة من البيانات. الحل استبدال المصفوفة بكائن يكون له حقول منفصلة لكل عنصر. مثال قبل إعادة التصميم احتواء المصفوفة row على نوعين مختلفين من البيانات (سلسلة نصية وعدد): في لغة Java: String[] row = new String[2]; row[0] = "Liverpool"; row[1] = "15"; في لغة C#‎: string[] row = new string[2]; row[0] = "Liverpool"; row[1] = "15"; في لغة PHP: $row = array(); $row[0] = "Liverpool"; $row[1] = 15; في لغة ...

المشكلة تحتوي التوابع على نفس المجموعة المتكررة من المعاملات. الحل استبدال هذه المعاملات بكائنٍ واحد. مثال قبل إعادة التصميم تمرير نفس مجموعة المعاملات إلى توابع الصنف Customer: تحتوي التوابع على نفس المجموعة المتكررة من المعاملات. بعد إعادة التصميم تبديل كائن واحد بتلك المعاملات وتمريره إلى توابع الصنف Customer التي تشترك بنفس مجموعة المعاملات: استبدال هذه المعاملات بكائنٍ واحد. لم إعادة التصميم؟ غالبًا ما تُصادَف مجموعات متطابقة من المعاملات داخل العديد من التوابع. الأمر الذي يؤدي إلى تكرار الشيفرة البرمجية للمعاملات ...

المشكلة إطلاق استثناء يمكن لاختبار بسيط أن يحل محله. الحل يستعاض عن الاستثناء باختبار الحالة. مثال قبل إعادة التصميم معالجة الاستثناء الحاصل عند وقوع الفهرس periodNumber خارج حدود مصفوفة القيم values وإعادة القيمة 0 آنذاك: في لغة Java: double getValueForPeriod(int periodNumber) { try { return values[periodNumber]; } catch (ArrayIndexOutOfBoundsException e) { return 0; } } في لغة C#‎: double GetValueForPeriod(int periodNumber) { try { return values[periodNumber]; ...

المشكلة تحتوي الأصناف الفرعية على توابع تؤدي نفس العمل. الحل جعل التوابع متطابقة ثم نقلها إلى الصنف الأعلى ذي الصلة. مثال قبل إعادة التصميم يحتوي الصنفان الفرعيان Soldier و Tank على التابع ()getHealth الذي يؤدي نفس العمل: تحتوي الأصناف الفرعية على التابع ()getHealth تؤدي نفس العمل. بعد إعادة التصميم نقل التابع ()getHealth إلى الصنف Unit الأب وإزالته من الأصناف الفرعية: نقل التابع ()getHealth إلى الصنف الأعلى. لم إعادة التصميم؟ تنمو الأصناف الفرعية وتتطور بشكل مستقل عن بعضها البعض، مما يتسبب ...

المشكلة يحتوي صنفان على نفس الحقل. الحل إزالة الحقل من الأصناف الفرعية ونقله إلى الصنف الأعلى. مثال قبل إعادة التصميم يحتوي الصنفان Tank و Soldier المتفرعان من الصنف Unit على الحقل المشترك health: يحتوي الصنفان Soldier و Tank على نفس الحقل health. بعد إعادة التصميم إزالة الحقل health من الأصناف الفرعية (الصنف Soldier والصنف Tank) ونقله إلى الصنف Unit الأب: إزالة الحقل health من الأصناف الفرعية ونُقل إلى الصنف الأب. لم إعادة التصميم؟ تنمو الأصناف الفرعية وتتطور بشكل منفصل، مما ...

المشكلة لديك مُنشئ (constructor) معقد يقوم بما هو أكثر من مجرد وضع قيم المعامل في حقول الكائن. الحل إنشاء تابع تصميم واستخدامه لاستبدال استدعاءات المُنشئ. مثال قبل إعادة التصميم وجود منشئ معقد للصنف Employee: في لغة Java: class Employee { Employee(int type) { this.type = type; } //... } في لغة C#‎: public class Employee { public Employee(int type) { this.type = type; } //... } في لغة PHP: class ...

يوضح هذا الدليل كيفية تضمين مُكوّن (component) عارض كوردوفا في تطبيقات منصة iOS الكبيرة. للمزيد من التفاصيل حول كيفية جعل تلك المكوّنات تتواصل مع بعضها، راجع دليل تطوير الإضافات. بدأ دعم العوارض في منصة iOS منذ الإصدار 1.4 كوردوفا، باستخدام مكوِّن Cleaver الذي بُنِي على قالب Xcode. منصة كوردوفا 2.0 والإصدارات الأحدث لا تدعم إلا التقديم المستند إلى المشروع الفرعي (subproject-based) للمكُوِّن Cleaver. تتطلب هذه الإرشادات على الأقل الإصدار الرابع من كوردوفا، والثامن من Xcode، بالإضافة إلى الملف config.xml من ...

يُشار إلى TypeScript على أنّها مجموعة عليا (superset) من JavaScript وتُترجم (compile) إليها. وهذا يعني بأن البرامج المكتوبة بلغة JavaScript هي برامج TypeScript صالحة كذلك، ولأنّها تُترجم إلى لغة JavaScript عاديّة، فيُمكن كتابة برامج بلغة TypeScript وترجمتها وتشغيلها في أي مكان يقبل تشغيل برمجيات JavaScript مثل المتصفّح، أو منصّة Node.js، أو أي مُحرّكٍ (engine) يدعم الإصدار ECMAScript 3 من لغة JavaScript أو أي إصدار أحدث منه. تدعم TypeScript مزايا JavaScript الجديدة والتي قيد التطوير، ما يشمل مزايا الإصدار ECMAScript 2015 ...

توصيف المشكلة تظهر المشكلة بعدَّة جوانب: استخدام الحقول الأساسيّة (primitives) بدلًا من الكائنات (objects) لأداء المهامّ البسيطة (مثل: عمليات العملة [currency] والمجالات [ranges] والسلاسل النصية [strings] المُخصَّصة للأرقام الهاتفية، …إلخ.). استخدام الثوابت (constants) لترميز المعلومات (مثل استخدام الثابت USER_ADMIN_ROLE = 1 للدلالة على المستخدمين ذوي الصلاحيّات الإداريّة). استخدام الثوابت النصيّة (string constants) كأسماءٍ للحقول (fields) في مصفوفات البيانات (data arrays). أسبابها تنشأ هذه المشكلة بسبب العبارة المُدمِّرة التي يفكّر بها المبرمجون بلحظة ضعفٍ: "حقلٌ واحدٌ فقط، ولتخزين معلومةٍ بسيطةٍ وحسب!"ولأنهم ...

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

توصيف المشكلة وجود العديد من الاستدعاءات المتسلسلة في الشيفرة، مثل: ‎$a->b()->c()->d()‎. أسبابها تحدث المشكلة عند طلب العميل (client request) كائنًا (object) آخر والذي بدوره يطلب كائنًا آخر ثالثًا وهكذا، مما يعني اعتماد العميل على التنقّل (navigation) في بنية الأصناف (class structure)، وبالتالي فإنّ أيّ تعديلٍ في تلك العلاقات سيتطلَّبُ إجراء التعديلات أيضًا على العميل بحدِّ ذاته. وما الحل؟ إخفاء التفويض (hide delegate) لحذف الاستدعاءات المُتسلسلة. قد يساعد -ببعض الحالات- التفكيرُ بسبب الوصول إلى آخر كائنٍ (object) مستدعى، وعندها يمكن اللجوء ...

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

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

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

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

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

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

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

يتلخّص هذا الجانب بعواقب إنشاء رابطٍ شديدٍ ازدواجيّ (ما بين صنفين [classes])، أو قد تظهر بدائل عنه كالتفويض المفرط (excessive delegation)، وتتمثل هذه المشكلة بالنقاط الآتية: التسلط على الكائنات الأخرى (feature envy) المشكلة: استخدام بعضُ التوابع بياناتِ الكائنات الأخرى أكثر ممّا تستخدم بياناتِها ذاتَها. الحل: إبقاء الأجزاء التي تتغيَّر بآنٍ واحدٍ في المكان ذاته معًا عبر نقلُ التوابع، أو استخراجُ التوابع. الارتباط الوثيق غير المناسب (inappropriate intimacy) المشكلة: استخدام أحد الأصناف الحقولَ والتوابعَ الداخليّة لصنفٍ آخر بكثرة. الحل: نقلُ التوابع ونقل ...