الفرق بين المراجعتين ل"Refactoring/duplicate observed data"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: تكرار البيانات المرُاقَبة (Duplicate Observed Data)}}</noinclude> == المشكلة == هل بيانات النطاق...')
 
سطر 32: سطر 32:
 
* قالب المُراقِب [[Refactoring/observer|Observer]].
 
* قالب المُراقِب [[Refactoring/observer|Observer]].
 
* التغليف الداخلي للحقول ([[Refactoring/self encapsulate field|Self Encapsulate Field]]).
 
* التغليف الداخلي للحقول ([[Refactoring/self encapsulate field|Self Encapsulate Field]]).
* الأصناف الواسعة ([[Refactoring/large class|Large Classes]])
+
* الأصناف الواسعة ([[Refactoring/large class|Large Classes]]).
  
 
== مصادر ==
 
== مصادر ==

مراجعة 14:53، 12 نوفمبر 2018

المشكلة

هل بيانات النطاق المخزنة في أصناف هي المسؤولة عن واجهة المستخدم الرسومية (GUI)؟

الحل

فصل البيانات في أصناف منفصلة، لضمان الاتصال والتزامن بين صنف النطاق وواجهة المستخدم الرسومية GUI.

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

إذا كنت تريد أن يكون لديك واجهات عرض متعددة لنفس البيانات (على سبيل المثال، تطبيق لسطح المكتب وتطبيق للهاتف المحمول). إذا لم تنجح في فصل GUI عن النطاق، ستمر بوقت عصيب جدًا لتجنب تكرار التعليمات البرمجية والوقوع في عدد كبير من الأخطاء.

فوائد تطبيق الحل

  • يمكن تقسيم المسؤولية بين أصناف منطق العمل وأصناف العرض (راجع مبدأ المسؤولية الفردية)، مما يجعل البرنامج أكثر قابلية للقراءة والفهم.
  • إذا كنت بحاجة إلى إضافة واجهة عرض جديدة، لن يكون إنشاء أصناف عرض جديدة بحاجة إلى أي تعديل لشيفرة منطق العمل (راجع مبدأ مفتوح/مغلق).
  • يمكن الآن لأشخاص مختلفين العمل علي منطق العمل وواجهات المستخدم.

متى يُترك هذا الحل؟

  • لا تنطبق تقنية إعادة التصميم هذه، والتي تُنفَّذ في نموذجها الكلاسيكي باستخدام قالب المُراقِب Observer، علي تطبيقات الويب، حيث يُعاد إنشاء كافة الأصناف بين الاستعلامات المُرسَلة إلى خادم الويب.
  • بنفس الطريقة، يمكن كذلك تبرير المبدأ العام لاستخراج منطق العمل إلى أصناف منفصلة لتطبيقات الويب. ولكن سيُنفذ هذا باستخدام تقنيات مختلفة لإعادة التصميم اعتمادًا على كيفية تصميم النظام الخاص بك.

آلية الحل

  1. إخفاء إمكانية الوصول المباشر إلى بيانات النطاق في صنف GUI. لهذا فمن الأفضل استخدام التغليف الداخلي للحقول (Self Encapsulate Field). فيمكنك إنشاء المتلقي والضابط لهذه البيانات.
  2. تُستخدم الضوابط لتعيين قيم الحقل الجديدة في معالجات أحداث صنف GUI. وسيتيح لك هذا تمرير هذه القيم إلى كائن النطاق المقترن.
  3. إنشاء صنف مجال ونسخ الحقول الضرورية من صنف GUI إليه. إنشاء المتلقي والضابط لجميع هذه الحقول.
  4. إنشاء نمط مراقب Observer لهذين الصنفين:  
    • أنشئ مصفوفة في صنف النطاق لتخزين كائنات المراقبة (كائنات GUI)، بالإضافة إلى توابع التسجيل والحذف والإشعار.
    •  أنشئ في صنف GUI حقل لتخزين المراجع في صنف النطاق بالإضافة إلى تابع update()‎، الذي سيتفاعل مع التغييرات في الكائن ويُحدِّث قيم الحقول في صنف GUI. علمًا بأنه يجب تأسيس تحديثات القيمة مباشرةً في التابع لتجنب العودية.
    • أنشئ مثيل النطاق في مُنشئ الصنف GUI واحفظه في حقل سبق إنشائه. وسجل كائن GUI كمراقب في كائن النطاق.
    • في ضوابط حقول صنف النطاق، استدع التابع لإشعار المراقب (وبعبارة أخرى، تابع للتحديث في الصنف GUI)، من أجل تمرير القيم الجديدة إلى GUI.
    • غيِّر ضوابط حقول الصنف GUI بحيث تُعيَّن قيم جديدة في كائن النطاق مباشرة. وانتبه إلى التأكد من أن القيم ليست موضوعة من خلال ضابط صنف نطاق وإلا سينتج عودية لانهائية.

انظر أيضًا

مصادر