هل يجب علي توفير أساليب الوصول/Getter Setters للمكونات العامة/المحمية في النموذج؟

Question

إذا كان لدي .Net Form يحتوي على مكون/كائن مثل مربع نص أحتاج إلى الوصول إليه من أحد الوالدين أو نموذج آخر، فمن الواضح أنني بحاجة إلى "ترقية" المعدل إلى هذا المكون إلى متغير المستوى الداخلي أو العام.

الآن، إذا كنت أقوم بتوفير متغير عام من نوع int أو سلسلة وما إلى ذلك.في صف النموذج الخاص بي، لن أفكر مرتين في استخدام Getters و(ربما) Setters حول هذا، حتى لو لم يفعلوا أي شيء آخر غير توفير الوصول المباشر إلى المتغير.

ومع ذلك، يبدو أن مصمم VS لا ينفذ مثل Getters/Setters لتلك الكائنات العامة التي تعد مكونات في النموذج (وبالتالي لا تتوافق مع ممارسات البرمجة الجيدة).

لذا فإن السؤال هو؛من أجل القيام "بالشيء الصحيح" هل يجب علي تغليف مكونات أو كائنات مصمم VS في Getter و/أو Setter؟

Answer 1

"ومع ذلك، يبدو أن مصمم VS لا ينفذ مثل Getters/Setters لتلك الكائنات العامة التي تعد مكونات في النموذج (وبالتالي لا تتوافق مع ممارسات البرمجة الجيدة)."

إذا كنت تقصد عناصر التحكم التي تقوم بسحبها وإسقاطها في النموذج، فسيتم وضع علامة عليها كأعضاء مثيل خاص وتتم إضافتها إلى مجموعة عناصر التحكم الخاصة بالنموذج.لماذا سيكونون غير ذلك؟يمكن أن يحتوي النموذج على أربعين أو خمسين عنصر تحكم، وسيكون من غير الضروري إلى حدٍ ما وغير عملي توفير مُحضر/أداة ضبط لكل عنصر تحكم في النموذج.يترك المصمم الأمر لك لتوفير الوصول المفوض إلى عناصر تحكم محددة عبر أداة getter/setters العامة.

المصمم يفعل الشيء الصحيح هنا.

Answer 2

أعتقد أن سبب عدم تنفيذ Getters وSetters للمكونات في النموذج هو أنها لن تكون "آمنة لمؤشر الترابط". ومن المفترض أن يتم تعديل كائنات Net فقط بواسطة مؤشر ترابط النموذج الذي أنشأها، إذا قمت بوضع getter وsetters من المحتمل أنك تفتحه لأي موضوع.بدلاً من ذلك، من المفترض أن تقوم بتنفيذ نظام تفويض حيث يتم تفويض التغييرات على هذه الكائنات إلى مؤشر الترابط الذي أنشأها وقام بتشغيلها هناك.

Answer 3

هذا مثال كلاسيكي للتغليف في التصميم الموجه للكائنات.

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

من المحتمل أن يتضمن الحل الناضج نقاط التصميم التالية:

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

وهذا لا يذكر حتى أشياء التطوير الفوقي مثل اختبارات الوحدة.

Answer 4

أفعل ذلك دائمًا، وإذا كنت تتبع تصميم MVP، فإن إنشاء أداة getter/setters لمكونات العرض الخاصة بك سيكون أحد متطلبات التصميم.

لا أفهم ما تقصده بـ "لا يتوافق مع ممارسات البرمجة الجيدة".مايكروسوفت تنتهك كثيراً لممارسات البرمجة الجيدة لتسهيل إنشاء أشياء على Visual Studio (من أجل التطوير السريع للتطبيقات) ولا أرى عدم وجود حروف/أدوات ضبط لعناصر التحكم كدليل على انتهاك أي من أفضل الممارسات.