نتائج البحث

المشكلة وجود صنفٍ (class) واحدٍ يقوم بمهامٍ عديدةٍ يمكن توزيعها على صنفين. الحل إنشاء صنفٍ جديدٍ ونقل بعض الحقول (fields) والتوابع (methods) إليه، والتي تتعلَّق بالمهام الوظيفيّة (functionality) لهذا الصنف الجديد. مثال قبل إعادة التصميم يحتوي الصنف Person على عددٍ من الحقول كاسم الشخص (name) ورمز منطقة المكتب (officeAreaCode) ورقمه (officeNumber)، وتابعًا للحصول على هذا الرقم باسم getTelephoneNumber، كما في مخطط الأصناف الآتي: الصنف Person يحتوي على عددٍ من الحقول كاسم الشخص (name) ورمز منطقة المكتب (officeAreaCode) ورقمه (officeNumber)، وتابعًا ...

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

المشكلة لا يعبِّر اسم التابع عن ما يقوم به. الحل إعادة تسمية التابع. مثال قبل إعادة التصميم لا يفسر اسم التابع ()getsnm في الصنف Customer ما يقوم به. لا يفسر اسم التابع ما يقوم به. بعد إعادة التصميم إعادة تسمية التابع ()getsnm إلى ()getSecondName الذي يصف ما يقوم به. يفسر اسم التابع ما يقوم به. لم إعادة التصميم؟ ربما كانت تسمية تابعٍ ما سيئة من البداية - على سبيل المثال، أنشأ شخصٌ ما التابع في عجلة ولم يهتم كفاية بتسميته ...

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

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

يتم إنشاء كائنات الصنف Method بواسطة التابع Object.method، وترتبط بكائن معين (وليس بالصنف وحسب). ويمكن استخدامها لاستدعاء التابع داخل الكائن، أو ككتلة (block) مرتبطة بمكرر (iterator). كما يمكن فك ارتباطها (unbound) من كائن محدد (سيؤدي ذلك إلى إنشاء الكائن UnboundMethod) ثم ربطها بآخر. class Thing def square(n) n*n end end thing = Thing.new meth = thing.method(:square) meth.call(9) #=> 81 [ 1, 2, 3 ...

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

تجعل التقنيات التي سيشار إليها في هذا القسم استدعاءات التوابع أبسط وأسهل للفهم والاستيعاب. سيؤدي ذلك بدوره إلى تبسيط الواجهات للتفاعل بين الأصناف. هذه التقنيات هي: إعادة تسمية التوابع (Rename Method) المشكلة: لا يعبِّر اسم التابع عن ما يقوم به. الحل: إعادة تسمية التابع. إضافة المعاملات (Add Parameter) المشكلة: لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات. الحل: إنشاء معامل جديد لتمرير البيانات الضرورية. حذف المعاملات (Remove Parameter) المشكلة: لا يُستخدم معاملٌ ما في متن التابع. الحل: إزالة المعامل غير ...

المشكلة هل السلوك المُنفَّذ في الصنف الأب مُستخدمٌ في صنف فرعي واحد فقط (أو أكثر)؟ الحل نقل هذا السلوك إلى الأصناف الفرعية. مثال قبل إعادة التصميم التابع ()getFuel الموجود في الصنف Unit الأب مُستخدم في صنف فرعي واحد فقط الذي هو Tank: التابع الموجود في الصنف الأب مُستخدم في صنف فرعي واحد فقط. بعد إعادة التصميم نقل التابع ()getFuel من الصنف الأب إلى الصنف الفرعي المستخدم فيه: نقل هذا التابع إلى الصنف الفرعي الذي يُستخدم فيه. لم إعادة التصميم؟ في ...

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

نحتاج إلى إعادة التصميم (قاعدة المرات الثلاث): عند قيامك بأيّة مهمةٍ للمرّة الأولى، فالمهم هو إنجازها والحصول على النتيجة وحسب. لدى قيامك بمهمةٍ مشابهةٍ للمرّة الثانية قد ترفض بادئ الأمر فكرة التكرار ولكنك ستجد نفسك تقوم بنفس العمل! عند قيامك بالمهمة للمرّة الثالثة، ستحتاج إعادة التصميم. عند إضافة ميّزةٍ (feature) جديدة تساعد عملية إعادة التصميم (refactoring) على فهم شيفرات المبرمجين الآخرين بشكلٍ أفضل، وعند العمل على الشيفرة غير الجيدة لأحدهم فعليك بإعادة تصميمها أولًا، وهذا ضروريٌّ إذ يصبح التحكُّم بالشيفرة ...

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

المشكلة استدعاء تابع استعلام (query method) وتمرير نتائجه كمعاملات لتابع آخر، في حين أنه يمكن لهذا التابع استدعاء الاستعلام مباشرة. الحل بدلًا من تمرير القيمة من خلال المعامل، حاول وضع استدعاء الاستعلام داخل متن التابع. مثال قبل إعادة التصميم تخزين القيمة التي يعيدها كلٌّ من التابعين ()getSeasonalDiscount و ()getFees في متغير ثم تمريرها إلى التابع ()discountedPrice: في لغة Java: int basePrice = quantity * itemPrice; double seasonDiscount = this.getSeasonalDiscount(); double fees = this.getFees(); double finalPrice = discountedPrice(basePrice, seasonDiscount, fees); في لغة C#‎: int basePrice ...

المشكلة ينقسم التابع إلى أجزاء، كل منها يتم تشغيله اعتمادًا على قيمة المعامل. الحل استخراج الأجزاء الفردية من التابع إلى توابعها الخاصة واستدعائها بدلًا من استدعاء التابع الأصلي. مثال قبل إعادة التصميم وجود تابع يدعى ()setValue يضبط قيمة الارتفاع والعرض بناءً على تمرير سلسلة نصية صريحة بذلك: في لغة Java: void setValue(String name, int value) { if (name.equals("height")) { height = value; return; } if (name.equals("width")) { width ...

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

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

مقدمة تعتمد لغة JavaScript التقليدية على الدوال والوراثة المعتمدة على سلسلة Prototype لبناء مكونات قابلة لإعادة الاستعمال، وقد يجد بعض المبرمجين هذه الطريقة غريبة ومرهقة، خاصّة الذين ألِفوا البرمجة كائنيّة التوجه التي تعتمد على الأصناف التي ترث وظيفة (functionality) الأصناف الأساس (base classes) وتُبنَى فيها الكائنات من هذه الأصناف. بدايةً من الإصدار ECMAScript 2015 المعروف كذلك بالإصدار ECMAScript 6، يُمكن لمبرمجي JavaScript بناء التطبيقات باستخدام البرمجة كائنيّة التوجّه المعتمِدة على الأصناف. وتسمح TypeScript للمطورين باستعمال هذه التقنيات الآن، وتُترجِمها إلى ...

يستدعي المعامل === كتلة التابع مع تمرير الكائن الواقع على يمينه كوسيط إلى المعامل الواقع على يساره كما هو الحال في Proc.call. هذا يَسمح لكائنٍ من النوع proc أن يكون هدفًا للكتلة when في التعليمة case. البنية العامة proc === obj→ result_of_proc‎ القيمة المعادة تعاد نتيجة الوسيط proc. انظر أيضا التابع ==: يتحقق من تساوي كائنين من النوع Method. مصادر قسم التابع ===‎ في الصنف Method‎ في توثيق روبي الرسمي.

يستدعي معامل الفهرسة [] الكتلة البرمجية للتابع، ويضبط قيم معاملات الكتلة عند القيم المعطاة ضمنه باستخدام صياغة مشابهة لاستدعاء التوابع ثم يعيد قيمة آخر تعبير تم تقييمه في الكتلة. لاحظ أنَّ ‎prc.()‎ يستدعي prc.call()‎ مع تمرير الوسائط المعطاة. وهي صياغة مختصرة لإخفاء التابع "call". بالنسبة للكائنات procs التي تم إنشاؤها باستخدام lambda أو ‎->()‎‎‎، سيُطلق خطأ إذا كان عدد المعاملات الممررة إلى proc غير صحيح. بالنسبة للكائنات proc التي تم إنشاؤها باستخدام Proc.new أو Kernel.proc، سيتم تجاهل المعاملات الإضافية بصمت، ...

يتحقق المعامل == من تساوي كائنين من النوع Method. يكون كائنان من النوع Method متساويين إن كانا مرتبطين بنفس الكائن، وكانا لهما نفس التعريف، وكان لهما نفس الصنف أو الوحدة (module) المالكة. البنية العامة meth == other_meth → true or false‎ القيمة المعادة تُعاد القيمة true إن كان الكائنان متساويين، وإلا فستُعاد القيمة false. انظر أيضا التابع ===: يستدعي كتلة التابع مع تمرير الكائن الواقع على يمينه كوسيط إلى المعامل الواقع على يساره كما هو الحال في Proc.call. مصادر قسم ...