الفرق بين المراجعتين ل"Refactoring/move field"

المراجعة الحالية بتاريخ 09:33، 2 مارس 2019

المشكلة

استخدام الحقل (field) في صنفٍ (class) ما أكثر من استخدامه في صنفه الأساسيّ.

الحل

إنشاء حقلٍ في صنفٍ جديدٍ وإعادة توجيه (redirect) كلَّ ما يستخدم هذا الحقل إلى ذلك الصنف المُنشَأ.

مثال

قبل إعادة التصميم

يستخدِم الصنفُ Class2 الحقلَ aField أكثر مما يستخدمه صنفه الأساسيّ Class1:

يستخدِم الصنفُ Class2 الحقلَ aField أكثر مما يستخدمه صنفه الأساسيّ Class1.

بعد إعادة التصميم

نُقِل الحقل aField إلى الصنف ذي الاستخدام الأكثر له وهو الصنف Class2:

نُقِل الحقل aField إلى الصنف ذي الاستخدام الأكثر له وهو الصنف Class2.

لم إعادة التصميم؟

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

آلية الحل

إن كان الحقل عامًّا (public) فستصبح عملية إعادة التصميم أسهل بجعل الحقل خاصًا (private) مع توفير توابع الوصول العامّة (public accessors) المناسبة له (لمزيد من التفاصيل راجع تغليف الحقول [Encapsulate Fields]).
إنشاء الحقل ذاته مع توابع الوصول إليه في الصنف المستقبِل (recipient class).
توفير المرجعيّة (reference) إلى الصنف المستقبِل، فقد يكون هنالك بالأصل حقلٌ (field) أو تابعٌ (method) يعيد كائنًا (object) مناسبًا، وإن لم يكن ذلك فلا بُدَّ من إنشاء حقلٍ أو كتابة تابعٍ جديدٍ لتخزين كائن الصنف المستقبِل، وبهذا تضمن سهولة الوصول إلى الصنف المستقبِل والحقل الجديد فيه.
تبديل كل مرجعيّات (references) الحقل السابق إلى استدعاءاتٍ (calls) لتوابع الوصول للحقل في الصنف المستقبِل، وإن لم يكن الحقل خاصًّا (private) فيجب وضع ذلك بعين الاعتبار في الصنف الأعلى (superclass) والأصناف الفرعيّة (subclasses).
حذف الحقل السابق في الصنف الأصليّ.

انظر أيضًا

مصادر

صفحة توثيق نقل الحقل في موقع refactoring.guru.

@@ سطر 9: / سطر 9: @@
 ==== قبل إعادة التصميم ====
-يستخدِم الصنفُ <code>Class2</code> في الشيفرة الآتية الحقلَ <code>aField</code> أكثر مما يستخدمه صنفه الأساسيّ <code>Class1</code>:<syntaxhighlight lang="java">
+يستخدِم الصنفُ <code>Class2</code> الحقلَ <code>aField</code> أكثر مما يستخدمه صنفه الأساسيّ <code>Class1</code>:
-class Class1 {
-  int aField
-   // …
-}
-class Class2 {
-    // استخدام متكرِّرٌ للحقل في الصنف السابق
-  }
-}
-</syntaxhighlight>
+[[ملف:Move_Field_-_Before.png|بديل=يستخدِم الصنفُ Class2 الحقلَ aField أكثر مما يستخدمه صنفه الأساسيّ Class1.|بدون|تصغير|180بك|يستخدِم الصنفُ Class2 الحقلَ aField أكثر مما يستخدمه صنفه الأساسيّ Class1.]]
 ==== بعد إعادة التصميم ====
-نُقِل الحقل <code>aField</code> إلى الصنف ذي الاستخدام الأكثر له وهو الصنف <code>Class2</code>:<syntaxhighlight lang="java">
+نُقِل الحقل <code>aField</code> إلى الصنف ذي الاستخدام الأكثر له وهو الصنف <code>Class2</code>:
-class Class1 {
-    // ...
-}
-class Class2 {
-    int aField
-}
-</syntaxhighlight>
+[[ملف:Move_Field_-_After.png|بديل=نُقِل الحقل <code>aField</code> إلى الصنف ذي الاستخدام الأكثر له وهو الصنف <code>Class2</code>.|بدون|تصغير|180بك|نُقِل الحقل <code>aField</code> إلى الصنف ذي الاستخدام الأكثر له وهو الصنف <code>Class2</code>.]]
 == لم إعادة التصميم؟ ==
-تُنقَل الحقول عادةً أثناء تطبيق تقنية الحل استخراج الصنف (Extract Class)، وليس من السهل تحديد الصنف الذي سيُنقل إليه الحقل، ولكن بشكلٍ عام، لتكن القاعدة: يُنقَل الحقل إلى الصنف الذي يحتوي معظمَ التوابع المعتمدة عليه أكثر من غيرها، وتفيد هذه القاعدة في أيّ حالةٍ مماثلةٍ يكون فيها الحقل في المكان الخطأ.
+تُنقَل الحقول عادةً أثناء تطبيق تقنية الحل [[Refactoring/extract class|استخراج الصنف]] (Extract Class)، وليس من السهل تحديد الصنف الذي سيُنقل إليه الحقل، ولكن بشكلٍ عام، لتكن القاعدة: يُنقَل الحقل إلى الصنف الذي يحتوي معظمَ التوابع المعتمدة عليه أكثر من غيرها، وتفيد هذه القاعدة في أيّ حالةٍ مماثلةٍ يكون فيها الحقل في المكان الخطأ.
 == آلية الحل ==
-# إن كان الحقل عامًّا (public) فستصبح عملية إعادة التصميم أسهل بجعل الحقل خاصًا (private) مع توفير توابع الوصول العامّة (public accessors) المناسبة له (لمزيد من التفاصيل راجع تغليف الحقول [Encapsulate Fields]).
+# إن كان الحقل عامًّا (public) فستصبح عملية إعادة التصميم أسهل بجعل الحقل خاصًا (private) مع توفير توابع الوصول العامّة (public accessors) المناسبة له (لمزيد من التفاصيل راجع [[Refactoring/encapsulate field|تغليف الحقول]] [Encapsulate Fields]).
 # إنشاء الحقل ذاته مع توابع الوصول إليه في الصنف المستقبِل (recipient class).
 # توفير المرجعيّة (reference) إلى الصنف المستقبِل، فقد يكون هنالك بالأصل حقلٌ (field) أو تابعٌ (method) يعيد كائنًا (object) مناسبًا، وإن لم يكن ذلك فلا بُدَّ من إنشاء حقلٍ أو كتابة تابعٍ جديدٍ لتخزين كائن الصنف المستقبِل، وبهذا تضمن سهولة الوصول إلى الصنف المستقبِل والحقل الجديد فيه.
@@ سطر 50: / سطر 34: @@
 * [https://refactoring.guru/move-field صفحة توثيق نقل الحقل في موقع refactoring.guru.]
 [[تصنيف:Refactoring]]
+[[تصنيف:Refactoring Techniques]]
+[[تصنيف:Refactoring Moving Features between Objects]]