عرض مصدر Refactoring/move method

<noinclude>{{DISPLAYTITLE:نقل التابع (Move Method)}}</noinclude>
== المشكلة ==
استخدام التابع (method) في صنفٍ (class) ما أكثر من استخدامه في صنفه الأساسيّ.

== الحل ==
إنشاء تابعٍ جديدٍ في الصنف الأكثر استخدامًا لذلك التابع ونقل شيفرته إلى التابع الجديد، ثم تحويل الشيفرة في التابع الأصليّ إلى مرجعيّةٍ للتابع الجديد في الصنف الآخر أو حذفه كليَّا.

=== مثال ===

==== قبل إعادة التصميم ====
يستخدِم الصنفُ <code>Class2</code> في الشيفرة الآتية التابعَ <code>aMethod()</code>‎ أكثر مما يستخدمه صنفه الأساسيّ <code>Class1</code>:<syntaxhighlight lang="java">
class Class1 {
  //...
  public double aMethod() {
    //...
  }
}
class Class2 {
    // استخدام متكرر للتابع في الصنف السابق
  }
}

</syntaxhighlight>

==== بعد إعادة التصميم ====
نُقِل التابع <code>aMethod()</code>‎ إلى الصنف ذي الاستخدام الأكثر له وهو الصنف <code>Class2</code>:<syntaxhighlight lang="java">
class Class1 {
  //...
}
class Class2 {
  public double aMethod() {
    // أصبح التابع في الصنف الذي يستخدمه أكثر
  }
}

</syntaxhighlight>

== لم إعادة التصميم؟ ==
# لجعل الأصناف (classes) أكثر ترابطًا على المستوى الداخلي، وذلك بنقل التابع إلى الصنف الذي يحتوي معظم البيانات التي يحتاجها.
# الحدُّ من الاعتماديّة (dependency) ما بين الأصناف أو التخليّ عنها، والمقصود بالاعتماديّة هو اعتماد الصنف الذي يستدعي التابع على الصنف الذي يحتوي ذلك التابع، ويبدو ذلك مفيدًا بشكلٍ خاصّ عندما يكون الصنف الذي يستدعي التابع معتمدًا بالأصل (قبل إعادة التصميم) على الصنف الذي نُقل إليه التابع.

== آلية الحل ==
# إعادة النظر بكلِّ الميّزات (features) التي يستخدمها التابع (method) في صنفه الأصليّ، فقد يكون من الأفضل نقلها كذلك، ولتكن القاعدة: تُنقَل الميّزات إلى التابع إن كانت غير مُستخدَمةٍ إلا من قِبله، أمّا بوجود توابع أخرى تستخدم تلك الميّزة فمن المهمّ نقلها أيضًا، إذ من الأسهل (في بعض الأحيان) نقلُ عددٍ كبيرٍ من التوابع بدلًا من تسوية العلاقات بينها عبر صنفين مختلفين.  كما ويجب التأكُّد من أنّ التابع غير مصرَّحٍ عنه (not declared) في الأصناف الأعلى (superclasses) أو الأصناف الفرعيّة (subclasses)، وإلا فإمّا أن تتخلى عن فكرة النقل أو أن تلجأ إلى التعدديّةً الشكليّةً (polymorphism) في الصنف المستقبِل (recipient class) لضمان فعاليّة (functionality) التابع المتوزِّع في عدَّة أصناف.
# التصريح عن التابع الجديد في الصنف المستقبِل (recipient class) وقد يُعطى اسمًا جديدًا معبِّرًا أكثر من الاسم السابق.
# توفير المرجعيّة إلى الصنف المستقبِل، فقد يكون هنالك بالأصل حقلٌ (field) أو تابعٌ (method) يعيد كائنًا (object) مناسبًا، وإن لم يكن ذلك فلا بُدَّ من إنشاء حقلٍ أو كتابة تابعٍ جديدٍ لتخزين كائن الصنف المستقبِل، وبهذا تضمن سهولة الوصول إلى الصنف المستقبِل والتابع الجديد فيه، وبقي تحويل التابع السابق إلى مرجعيّة (reference) لهذا التابع الجديد.
# التأكُّد من القدرة على حذف التابع السابق بأكمله، والإشارة بمرجعيّة إلى التابع الجديد في كافّة المواضع التي تستخدم التابع السابق.

== انظر أيضًا ==
* [[Refactoring/move field|نقل الحقول]].
* [[Refactoring/extract method|استخراج التوابع]].
* [[Refactoring/inline method|دمج التوابع]].

== مصادر ==
* [https://refactoring.guru/replace-method-with-method-object صفحة توثيق نقل التابع في موقع refactoring.guru.]
[[تصنيف:Refactoring]]