C#3.0 الخصائص التلقائية ، لماذا لا تصل إلى الحقل مباشرة؟

https://stackoverflow.com/questions/174198

05-07-2019
|

سؤال

مع النهج الجديد المتمثل في الحصول على GET/SET داخل الفئة من هذا القبيل:

public string FirstName {
        get; set;
    }

لماذا ببساطة لا تضع السمة FirstName العامة بدون ملحق؟

المحلول

اثنتان من المشكلات الكبيرة مع الوصول المباشر إلى متغير داخل الفئة (الحقل/السمة) هما:

1) لا يمكنك بسهولة البيانات ضد الحقول.

2) إذا قمت بفضح الحقول العامة من فصولك ، فلن تتمكن لاحقًا من تغييرها إلى خصائص (على سبيل المثال: لإضافة منطق التحقق من الصحة إلى المستقلين)

نصائح أخرى

لأنه ، في المستقبل ، إذا قمت بتغيير التنفيذ ، فلن ينهار الكود باستخدام الواجهة الحالية.

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

باستخدام خاصية ، يمكنك تقليل المخاطر بشكل فعال ، حيث ستتغير الواجهة.

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

يكون هذا النمط من التدوين أكثر فائدة عند مزج قابلية Acessibility مع Getter و Setter. على سبيل المثال ، يمكنك الكتابة:

public int Foo { get; private set; }

يمكنك أيضًا وضع جهاز داخلي ، أو حتى جعل Getter Private و Setter Public.

يتجنب هذا التدوين الحاجة إلى كتابة متغير خاص بشكل صريح فقط للتعامل مع المشكلة الكلاسيكية للقيمة القابلة للكتابة داخليًا/قابلة للقراءة من الخارج.

المفتاح هو أن المترجم يترجم الخاصية "تحت الغطاء" إلى زوج دالة ، وعندما يكون لديك رمز يبدو أنه يستخدم الخاصية ، فإنه يقوم بالفعل باستدعاء وظائف عند تجميعه وصولاً إلى IL.

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

أعتقد أن السائل يسأل لماذا لا يفعل ما يلي ...

public string FirstName { }

لماذا تهتم بالملحقات عندما يمكنك تقصيرها إلى ما سبق. أعتقد أن الإجابة هي أنه من خلال مطالبة الملحقات يجعل من الواضح للشخص الذي يقرأ الكود بأنه GET/SET قياسي. بدونهم يمكنك أن ترى أعلاه من الصعب تحديد تنفيذ هذا تلقائيًا.

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

إن القيام بهذا العمل مقدمًا والتمسك بنقطة التوقف على الإكسسور أسهل بكثير من البدائل.

بالنسبة إلى 99 ٪ من الحالات ، فإن كشف مجال عام أمر جيد.

النصيحة المشتركة هي استخدام الحقول: "إذا قمت بفضح الحقول العامة من فصولك ، فلن تتمكن لاحقًا من تغييرها إلى خصائص". أعلم أننا جميعًا نريد أن يكون رمزنا مقاومًا في المستقبل ، ولكن هناك بعض المشاكل في هذا التفكير:

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

public class MyClass : IMyClass
{
    public static IMyClass New(...)
    {
        return new MyClass(...);
    }
}

إنها مشكلة صعبة ، في محاولة لصنع التعليمات البرمجية التي ستعمل في مستقبل غير مؤكد. صعب جدا.

هل لدى أي شخص مثال على الوقت عند استخدام خصائص تافهة أنقذ لحم الخنزير المقدد؟

يحافظ على تغليف الكائن ويقلل الكود ليكون أكثر سهولة في القراءة.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow