الفرق بين المراجعتين لصفحة: «Refactoring/replace constructor with factory method»
Khaled-yassin (نقاش | مساهمات) أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: استبدال المُنشئ بتابع التصميم (Replace Constructor with Factory Method)}}</noinclude> = المشكلة = لديك...' |
Khaled-yassin (نقاش | مساهمات) |
||
سطر 78: | سطر 78: | ||
= فوائد تطبيق الحل = | = فوائد تطبيق الحل = | ||
* لا يعيد تابع التصميم كائنًا من الصنف الذي أُستُدعيَ منه بالضرورة. وكثيرًا ما يكون من أصنافه الفرعية، مُختارًا بحسب الوسائط المقدمة إلى التابع. | * لا يعيد تابع التصميم كائنًا من الصنف الذي أُستُدعيَ منه بالضرورة. وكثيرًا ما يكون من أصنافه الفرعية، مُختارًا بحسب الوسائط المقدمة إلى التابع. | ||
* يمكن لتابع التصميم أن يكون له اسم أفضل يصف ما يفعله ويعيده وكيف، على سبيل المثال Troops::GetCrew(myTank). | * يمكن لتابع التصميم أن يكون له اسم أفضل يصف ما يفعله ويعيده وكيف، على سبيل المثال <code>Troops::GetCrew(myTank)</code>. | ||
* يمكن لتابع التصميم أن يعيد كائنًا مُنشَأً بالفعل، على عكس المُنشئ، الذي يخلق دائما مثيل جديد. | * يمكن لتابع التصميم أن يعيد كائنًا مُنشَأً بالفعل، على عكس المُنشئ، الذي يخلق دائما مثيل جديد. | ||
مراجعة 14:15، 5 فبراير 2019
المشكلة
لديك مُنشئ معقد يقوم بما هو أكثر من مجرد وضع قيم المعامل في حقول الكائن.
الحل
إنشاء تابع تصميم واستخدامه لاستبدال استدعاءات المُنشئ.
مثال
قبل إعادة التصميم
في لغة Java:
class Employee {
Employee(int type) {
this.type = type;
}
//...
}
في لغة C#:
public class Employee
{
public Employee(int type)
{
this.type = type;
}
//...
}
في لغة PHP:
class Employee {
// ...
public function __construct($type) {
$this->type = $type;
}
// ...
}
بعد إعادة التصميم
في لغة Java:
class Employee {
static Employee create(int type) {
employee = new Employee(type);
// do some heavy lifting.
return employee;
}
//...
}
في لغة C#:
public class Employee
{
public static Employee Create(int type)
{
employee = new Employee(type);
// do some heavy lifting.
return employee;
}
//...
}
في لغة PHP:
class Employee {
// ...
static public function create($type) {
$employee = new Employee($type);
// do some heavy lifting.
return $employee;
}
// ...
}
لم إعادة التصميم؟
يرتبط السبب الأكثر وضوحًا لاستخدام تقنية إعادة التصميم هذه باستبدال شيفرة النوع بالأصناف الفرعية.
فإذا كان لديك كائن سبق إنشاؤه في شيفرة برمجية ومُررت إليه قيمة النوع المشفر. بعد استخدام تابع إعادة التصميم، تظهر عدة أصناف فرعية، ومنها، تحتاج إلى إنشاء كائنات اعتمادًا على قيمة النوع المشفر. ويعد تغيير المُنشئ الأصلي بشكل يجعل إعادة كائنات أصناف فرعية شيئًا مستحيلًا، وبدلًا من ذلك يُنشأ تابع تصميم ثابت يعيد كائنات الأصناف الضرورية، وبعد ذلك يستبدل جميع استدعاءات المُنشئ الأصلي.
يمكن أيضًا استخدام توابع التصميم في حالات أخرى، عندما لا تكون المُنشِآت على القدر المناسب للمهمة. ويمكن أن تكون هامة عند محاولة تغيير القيمة إلى مرجع. كما يمكن استخدامها أيضا لتحديد أنماط إنشاء مختلفة والتي تتجاوز عدد وأنواع المعاملات.
فوائد تطبيق الحل
- لا يعيد تابع التصميم كائنًا من الصنف الذي أُستُدعيَ منه بالضرورة. وكثيرًا ما يكون من أصنافه الفرعية، مُختارًا بحسب الوسائط المقدمة إلى التابع.
- يمكن لتابع التصميم أن يكون له اسم أفضل يصف ما يفعله ويعيده وكيف، على سبيل المثال
Troops::GetCrew(myTank)
. - يمكن لتابع التصميم أن يعيد كائنًا مُنشَأً بالفعل، على عكس المُنشئ، الذي يخلق دائما مثيل جديد.
آلية الحل
- أنشئ تابع تصميم. ثم ضع استدعاءً للمُنشئ الحالي داخله.
- استبدل جميع استدعاءات المُنشئ باستدعاءات إلى تابع التصميم.
- اجعل المُنشئ خاصًا.
- تحقق من شيفرة المُنشئ وحاول عزل الشيفرة غير ذات الصلة المباشرة بإنشاء كائن من الصنف الحالي، وانقل هذه شيفرة إلى تابع التصميم.
انظر أيضًا
- تغيير القيمة إلى مرجع (Change Value to Reference).
- تبديل رموز الأنواع بالأصناف الفرعية (Replace Type Code with Subclasses).
- تابع التصميم (Factory Method).