it-swarm.asia

الحقول العامة مقابل الخصائص التلقائية

يتم إخبارنا غالبًا بأنه يتعين علينا حماية التغليف عن طريق إنشاء طرق getter و setter (الخصائص في C #) لحقول الفصل ، بدلاً من تعريض الحقول للعالم الخارجي.

ولكن هناك عدة مرات عندما يكون الحقل موجودًا فقط للاحتفاظ بقيمة ولا يتطلب أي حساب للحصول عليه أو تعيينه. بالنسبة إلى هؤلاء ، سنفعل كل هذا الرقم:

public class Book
{
    private string _title;

    public string Title
    {
          get{ return _title;  }
          set{ _title = value; }
    }
}

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

بعد ذلك تأتي C # 3.0 وأرى أنها أضافت خصائص تلقائية:

public class Book
{
    public string Title {get; set;} 
}

وهو أكثر أناقة ، وأنا ممتن لذلك ، ولكن في الحقيقة ، ما هو مختلف تمامًا عن مجرد إنشاء مجال عام؟

public class Book
{
    public string Title;
}
316
I. J. Kennedy

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

الخصائص مقابل المتغيرات العامة

  • يعمل الانعكاس بشكل مختلف على المتغيرات مقابل الخصائص ، لذلك إذا كنت تعتمد على الانعكاس ، فمن الأسهل استخدام جميع الخصائص.
  • لا يمكنك databind مقابل متغير.
  • تغيير المتغير إلى خاصية هو تغيير فاصل. فمثلا:

    TryGetTitle(out book.Title); // requires a variable
    
160
Michael Stum

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

لا يدعم مصحح أخطاء CLR نقاط فصل البيانات (تفعل معظم مصححات الأخطاء الأصلية). وبالتالي ، لا يمكن تعيين نقطة توقف على القراءة أو الكتابة لحقل معين في الفصل الدراسي. هذا محدود للغاية في بعض سيناريوهات التصحيح.

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

76
JaredPar

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

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

61
Rex M

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

57
MartinStettner

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

44
Zaid Masud

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

10
Arnaldo

لا حرج في صنع حقل public. ولكن تذكر أن إنشاء getter/setter مع حقول private ليس مغلفًا. IMO ، إذا كنت لا تهتم بالميزات الأخرى لـ Property ، فيمكنك أيضًا جعلها public.

8
fastcodejava

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

7
Reed Copsey

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

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

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

0
James Black

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

0
TrtlBoy