الفرق بين المراجعتين ل"Refactoring/change reference to value"
اذهب إلى التنقل
اذهب إلى البحث
Khaled-yassin (نقاش | مساهمات) (أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: تبديل المرجع إلى قيمة (Change Reference to Value)}}</noinclude> = المشكلة = وجود كائن مرجع صغير جد...') |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق) |
||
| (3 مراجعات متوسطة بواسطة مستخدمين اثنين آخرين غير معروضة) | |||
| سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE: تبديل المرجع إلى قيمة (Change Reference to Value)}}</noinclude> | <noinclude>{{DISPLAYTITLE: تبديل المرجع إلى قيمة (Change Reference to Value)}}</noinclude> | ||
| − | = المشكلة = | + | == المشكلة == |
| − | وجود كائن مرجع صغير جدًا | + | وجود كائن مرجع صغير جدًا نادرًا ما يتغيَّر لتبرير إدارة دورة حياته. |
| + | == الحل == | ||
| + | تحويله إلى كائن قيمة (value object). | ||
| + | |||
| + | === مثال === | ||
| + | |||
| + | ==== قبل إعادة التصميم ==== | ||
| + | مخطط يوضح كيفية ارتباط الصنفين <code>Currency</code> و <code>Customer</code>:[[ملف:Change Reference to Value - Before.png|بديل=مخطط يوضح كيفية ارتباط الصنفين Currency و Customer.|بدون|تصغير|مخطط يوضح كيفية ارتباط الصنفين <code>Currency</code> و <code>Customer</code>.]] | ||
| − | == | + | ==== بعد إعادة التصميم ==== |
| − | + | إعادة تصميم المخطط السابق للتتحول العلاقة الرابطة للصنفين <code>Currency</code> و <code>Customer</code> إلى علاقة has a (أي بمجرد وجود كائن <code>Customer</code> فلا بد من وجود كائن <code>Currency</code> له).[[ملف:Change Reference to Value - After.png|بديل=مخطط يوضح كيفية ارتباط الصنفين Currency و Customer بعلاقة has a (أي بمجرد وجود كائن Customer فلا بد من وجود كائن Currency له).|بدون|تصغير|مخطط يوضح كيفية ارتباط الصنفين <code>Currency</code> و <code>Customer</code> بعلاقة has a (أي بمجرد وجود كائن <code>Customer</code> فلا بد من وجود كائن <code>Currency</code> له).]] | |
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
قد يرجع التبديل من مرجع إلى قيمة إلى عدم ملائمة العمل مع المرجع. تتطلب المراجع إدارة من جهتك: | قد يرجع التبديل من مرجع إلى قيمة إلى عدم ملائمة العمل مع المرجع. تتطلب المراجع إدارة من جهتك: | ||
| − | * فهي تتطلب | + | * فهي تتطلب دائمًا طلب الكائن اللازم من الذاكرة المُخزَّن فيها. |
* قد يكون من غير المريح العمل مع المراجع في الذاكرة. | * قد يكون من غير المريح العمل مع المراجع في الذاكرة. | ||
| − | * يكون العمل مع المراجع صعبًا للغاية | + | * يكون العمل مع المراجع صعبًا للغاية مقارنةً بالقيم، في الأنظمة الُموزَعة والموازية. |
| − | تكون القيم مفيدة بشكل خاص إذا كنت | + | تكون القيم مفيدة بشكل خاص إذا كنت تُفضِّل أن يكون لديك كائنات غير قابلة للتغيير، عن الكائنات التي قد تتغير حالتها أثناء دورة حياتها. |
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
| − | * أحد الخواص | + | * أحد الخواص المهمة للكائنات أن تكون غير قابلة للتغيير. يجب الحصول على نفس النتيجة عند كل استعلام يُعيد قيمة كائن. إذا كان ذلك صحيحًا، لا تنشأ مشاكل إذا كان هناك العديد من الكائنات التي تمثِّل نفس الشيء. |
* من السهل جدًا تنفيذ القيم. | * من السهل جدًا تنفيذ القيم. | ||
== مساوئ تطبيق الحل == | == مساوئ تطبيق الحل == | ||
| − | * إذا كانت القيمة قابلة للتغيير، يجب التأكد من أنه إذا تغير أي | + | * إذا كانت القيمة قابلة للتغيير، يجب التأكد من أنه إذا تغير أي كائن، فستُحدََّث القيم الموجودة في كافة الكائنات الأخرى التي تمثل نفس الكيان. وهو أمر مرهق جدًا إذ من الأسهل إنشاء مرجع لهذا الغرض. |
== آلية الحل == | == آلية الحل == | ||
| − | # جعل الكائن غير قابل للتغيير. يجب ألَّا يكون للكائن أي ضابط أو تابع آخر يُغيّر من حالته وبياناته (قد يساعد هنا [[Refactoring/remove setting method|تابع إزالة الإعدادات]]). ويكون | + | # جعل الكائن غير قابل للتغيير. يجب ألَّا يكون للكائن أي ضابط أو تابع آخر يُغيّر من حالته وبياناته (قد يساعد هنا [[Refactoring/remove setting method|تابع إزالة الإعدادات]]). ويكون الباني هو المكان الوحيد الذي يجب تعيين بيانات حقول كائن قيمة فيه. |
# إنشاء تابع مقارنة لتكون قادرًا على مقارنة قيمتين. | # إنشاء تابع مقارنة لتكون قادرًا على مقارنة قيمتين. | ||
| − | # | + | # التحقق ما إذا كان يمكن حذف تابع إعادة التصميم وجعل باني الكائن عامًا. |
== انظر أيضًا == | == انظر أيضًا == | ||
| − | * [[Refactoring/remove setting method|تابع إزالة الإعدادات]] | + | * [[Refactoring/remove setting method|تابع إزالة الإعدادات]]. |
| − | * | + | * [[Refactoring/change value to reference|تبديل القيمة إلى مرجع]]. |
== مصادر == | == مصادر == | ||
المراجعة الحالية بتاريخ 09:49، 2 مارس 2019
المشكلة
وجود كائن مرجع صغير جدًا نادرًا ما يتغيَّر لتبرير إدارة دورة حياته.
الحل
تحويله إلى كائن قيمة (value object).
مثال
قبل إعادة التصميم
مخطط يوضح كيفية ارتباط الصنفين Currency و Customer:
بعد إعادة التصميم
إعادة تصميم المخطط السابق للتتحول العلاقة الرابطة للصنفين Currency و Customer إلى علاقة has a (أي بمجرد وجود كائن Customer فلا بد من وجود كائن Currency له).
لم إعادة التصميم؟
قد يرجع التبديل من مرجع إلى قيمة إلى عدم ملائمة العمل مع المرجع. تتطلب المراجع إدارة من جهتك:
- فهي تتطلب دائمًا طلب الكائن اللازم من الذاكرة المُخزَّن فيها.
- قد يكون من غير المريح العمل مع المراجع في الذاكرة.
- يكون العمل مع المراجع صعبًا للغاية مقارنةً بالقيم، في الأنظمة الُموزَعة والموازية.
تكون القيم مفيدة بشكل خاص إذا كنت تُفضِّل أن يكون لديك كائنات غير قابلة للتغيير، عن الكائنات التي قد تتغير حالتها أثناء دورة حياتها.
فوائد تطبيق الحل
- أحد الخواص المهمة للكائنات أن تكون غير قابلة للتغيير. يجب الحصول على نفس النتيجة عند كل استعلام يُعيد قيمة كائن. إذا كان ذلك صحيحًا، لا تنشأ مشاكل إذا كان هناك العديد من الكائنات التي تمثِّل نفس الشيء.
- من السهل جدًا تنفيذ القيم.
مساوئ تطبيق الحل
- إذا كانت القيمة قابلة للتغيير، يجب التأكد من أنه إذا تغير أي كائن، فستُحدََّث القيم الموجودة في كافة الكائنات الأخرى التي تمثل نفس الكيان. وهو أمر مرهق جدًا إذ من الأسهل إنشاء مرجع لهذا الغرض.
آلية الحل
- جعل الكائن غير قابل للتغيير. يجب ألَّا يكون للكائن أي ضابط أو تابع آخر يُغيّر من حالته وبياناته (قد يساعد هنا تابع إزالة الإعدادات). ويكون الباني هو المكان الوحيد الذي يجب تعيين بيانات حقول كائن قيمة فيه.
- إنشاء تابع مقارنة لتكون قادرًا على مقارنة قيمتين.
- التحقق ما إذا كان يمكن حذف تابع إعادة التصميم وجعل باني الكائن عامًا.