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




class properties (7)

غالباً ما يتم إخبارنا بأننا يجب أن نحمي التغليف عن طريق جعل أساليب 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;
}

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

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

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


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

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

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


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

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

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

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

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


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


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


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

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





automatic-properties