نتائج البحث

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

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

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

توصيف المشكلة تكرار مجموعةٍ من المتغيِّرات (variables) (كتلك المُستخدَمة كمعاملاتٍ [parameters] للربط مع قاعدة البيانات مثلًا) بشكلٍ متطابقٍ تمامًا في عدّة أجزاء من الشيفرة، إذ يجب تحويل تلك المجموعات إلى أصنافها (classes) الخاصّة بها. أسبابها تُعزى المشكلة عمومًا للبُنية (structure) البرمجيّة الضعيفة (أو ما يُعرف بمصطلح copypasta programming)، وللتحقُّقِ من وجود هذه المشكلة بالشيفرة احذف إحدى القيم، فإنْ حدث خللٌ نتيجة الحذف فالمشكلة قائمة ويجب علاجها، وإلّا فتلك إشارةٌ حسنةٌ ومن المحبَّذ تجميعُ هذه المتغيِّرات في كائنٍ واحدٍ. وما الحل؟ ...

توصيف المشكلة استخدام أحد الأصناف (class) الحقولَ (fields) والتوابعَ (methods) الداخليّة لصنفٍ آخر بكثرة. أسبابها تعاملُ الأصناف (classes) مع بعضها بكثرةٍ، وهذا ما يجب أن تكون على درايةٍ به، إذ إنّ التصميم الجيّد يشترط الحدَّ من التواصل فيما بينها ما أمكن، وهذا سيسهِّل صيانتها (maintenace) وإعادة استخدامها (reuse). وما الحل؟ نقلُ التوابع (move methods) ونقل الحقول (move fields) من الصنف الحاليّ إلى الصنف الآخر الذي تُستخدَم فيه، وهو الحلُّ الأبسط عندما لا يحتاج الصنف الأول تلك الحقول والتوابع المنقولة. استخراج ...

توصيف المشكلة تحتوي الحقول المؤقَّتة على قيمٍ (وتُستخدَم وفقًا لها في الكائنات [objects]) ضمن شروطٍ مُحدَّدة، وتبقى فارغةً عند عدم تحقٌّق تلك الشروط. أسبابها تُخصَّصُ الحقول المؤقتة لاستخدامها في الخوارزميات التي تتطلَّب عددًا كبيرًا من المُدخلات (inputs)، فبدلًا من إنشاء الكثير من المعاملات في التابع (method parameters) يلجأ المُبرمِج لإنشاء حقولٍ مؤقَّتة لاحتواء البيانات المطلوبة في الصنف (class)، وبهذا فإنّ استخدام تلك الحقول لا يتعدّى تنفيذَ الخوارزميّة المُحدَّدة (ولا وظيفة أخرى لها خارج ذلك النطاق)، ويجعل وجودُ تلك الحقول من ...

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

ملاحظة قبل البدء إنّ مشكلة تغيير الأصناف المتعدِّدة هي المشكلة المعاكسة تمامًا لمشكلة التغيير المتشعِّب (Divergent Change)، إذ إنّ التغيير المتشعِّب هو مجموع التغييرات الكثيرة التي تُجرَى في صنفٍ (class) واحدٍ، أما تغيير الأصناف المتعدِّدة فهو تغييرٌ واحدٌ يُجرَى في العديد من الأصناف. توصيف المشكلة يتطلَّبُ أيُّ تعديلٍ تقوم به إجراءَ تغييراتٍ طفيفةٍ بأصناف (classes) متفرِّقة. أسبابها توزيع مهمةٍ واحدةٍ على الكثير من الأصناف، ويحدث هذا نتيجةً للتطبيق المفرط للتغيير المُتشعِّب (Divergent Change). وما الحل؟ نقل سلوك (behaviour) الأصناف إلى ...

توصيف المشكلة وجود أصنافٍ (classes) أو توابعَ (methods) أو حقولٍ (fields) أو معاملاتٍ (parameters) غير مُستخدَمة في الشيفرة. أسبابها إنشاء عناصرَ إضافيّةٍ "قد" يحتاجها المبرمج مستقبلًا لميّزات يُخطِّط لها (وقد لا تُنفَّذ أصلًا)، وغير مستخدمةٍ بالوقت الحاليّ، مما يجعل الشيفرة أكثر صعوبةً بالفهم والدعم. وما الحل؟ هدم الهيكليّة الهرميّة (collapse hierarchy) لإزالة الأصناف المُجرَّدة (abstract classes) غير المُستخدَمة. دمج الأصناف (inline classes) للحدُّ من عمليات تفويض المهامّ (delegation) غير الضروريّة لصنفٍ آخر. دمج التوابع (inline methods) للتخلُّص من التوابع عديمة ...

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

توصيف المشكلة تنتُج هذه المشكلة عن احتواء شيفرة التابع على الكثير من الأسطر؛ فهو أمرٌ يدعو للتساؤل حقًا إن كان التابع بأكثر من 10 أسطر! لِمَ؟ أسبابها إنَّ ما يحدث دائمًا أنْ يُضاف للتابع لا أن يُحذَف منه! وذلك لسهولة كتابة الإضافات للشيفرة مقارنةً مع قراءتها، ولن تظهر هذه المشكلة واضحةً إلا بعد تفاقمها ووصولها لحدِ لا يُحتمَل، وكذلك يجد المبرمج أنَّ كتابة تابعٍ جديدٍ أكثرُ مشقّةً من الإضافة لتابعٍ موجودٍ مسبقًا، إذ يفكر: "هما سطران وحسب، ولا داعي لتخصيص ...

توصيف المشكلة عندما يكون للصنف (class) مهمةٌ واحدةٌ فقط وهي تفويض المهام (delegation) لصنفٍ آخر، فما أهمية وجوده بالأصل؟ أسبابها قد تنتج المشكلة عن التخلُّص المفرط من الاستدعاءات المتسلسلة كعلاجٍ لمشكلة سلاسل الرسائل (message chains). أو قد تنتُج عن النقل التدريجيّ للصنف (class) إلى أصناف أخرى ليبقى الصنف الأصليّ فارغًا إلا من أوامر التفويض (delegation). وما الحل؟ حذف الوسيط (remove middle man) إن كانت معظم أصناف التابع (method's classes) تفوِّض المهام (delegate) إلى صنفٍ آخر. إليك المزيد ستحصل بحلِّ المشكلة ...

من مشاكل الشيفرات أيضًا التطبيقُ الخطأ وغير المكتمل لمبادئ البرمجة كائنية التوجّه (Object-Oriented)، مثل: استخدام الأصناف البديلة (alternative) ذات الواجهات (interfaces) المختلفة المشكلة: التطابق بالمهام ما بين صنفين ولكن بأسماءٍ مختلفةٍ لتوابعهما. الحل: حذف أحد الصنفين بعد تنفيذ إحدى الحلول الآتية: إعادة تسمية التوابع (methods) لتصبح متطابقةً بكافّة الأصناف البديلة، أو توحيد التوقيع (signature) وتعريف الاستخدام ما بين التوابع (إمّا بنقل التابع أو إضافة المعاملات أو دمج التوابع عبر المعاملات)، أو استخراج صنفٍ أعلى وجعلهما صنفين فرعيين له (إن كان التطابق جزئيًا). الوراثة الفائضة (refused bequest) ...

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

توصيف المشكلة وجود ما يزيد عن ثلاثة أو أربعة معاملات (parameters) مُمرَّرة للتابع (method). أسبابها قد تحدث هذه المشكلة عند دمج عدّة خوارزمياتٍ بنفس التابع (method)، إذ تُستخدَم المعاملات (parameters) الكثيرة لتحديد الخوارزمية التي ستُنفَّذ وآليّتها. أو قد تنتج المشكلة عن محاولة المبرمج أو المطوِّر لجعل الأصناف (classes) أكثر استقلاليةً عن بعضها البعض. فمثلًا: عند نقل الشيفرة التي تنشِئ الكائنات (objects) -اللازمة لأحد التوابع- من داخل التابع إلى الشيفرة التي تستدعي ذلك التابع سيتطلَّبُ تمرير تلك الكائنات إلى التابع كمعاملاتٍ ...

ملاحظة قبل البدء إنّ مشكلة التغيير المتشعِّب هي المشكلة المعاكسة تمامًا لمشكلة تغيير الأصناف المتعدِّدة (Shotgun Surgery)، إذ إنّ التغيير المتشعِّب هو مجموع التغييرات الكثيرة التي تُجرَى في صنفٍ (class) واحدٍ، أما تغيير الأصناف المتعدِّدة فهو تغييرٌ واحدٌ يُجرَى في العديد من الأصناف. توصيف المشكلة الحاجة لتغيير الكثير من التوابع التي لا علاقة لها بالأمر بمجرَّد إحداث أيّ تغيير في الصنف (class)، فمثلًا؛ لدى إضافة منتجٍ جديدٍ عليك تعديل التوابع المسؤولة عن البحث عن المنتجات وعرضها وتنظيمها، وهذا مستهلكٌ للوقت ...

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

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

توصيف المشكلة لا تلبِّي أصناف المكتبة (library classes) كافّة احتياجات البرنامج مع استمرار تطوُّره، ولا يمكن تعديلها لأنّها مُخصَّصةٌ للقراءة فقط (read-only). أسبابها عدم تزويد مُطوِّر المكتبة كافَّةَ الميّزات (features) التي تحتاجها في البرنامج أو امتناعه عن تعريفَ استخدامها (implement). وما الحل؟ لتعريف بعض التوابع (methods) في المكتبة عليك بتعريف التوابع الدخيلة (introduce foreign methods). أمّا لإجراء تغييراتٍ واسعةٍ في صنف المكتبة فعليك بتعريف الإضافات المحليّة (introduce local extensions). إليك المزيد سيكون حلُّ المشكلة كفيلًا بالتقليل من تكرار الشيفرات (duplications)، ...

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