c# - قصيرة - مشهد عن المحافظة على ممتلكات المدرسة




هل هناك أي أسباب لاستخدام الممتلكات الخاصة في C#؟ (9)

أدركت للتو أنه يمكن استخدام بنية الخاصية C # أيضًا مع معدِّل وصول خاص :

private string Password { get; set; }

على الرغم من أن ذلك مثير للاهتمام من الناحية الفنية ، لا يمكنني تخيل متى سأستخدمه حيث يتضمن المجال الخاص حفلًا أقل :

private string _password;

ولا يمكنني تخيل متى أحتاج إلى أن أتمكن من الحصول على داخليًا ولكن لا يتم تعيينه أو تعيينه ولكن لا تحصل على حقل خاص:

private string Password { get; }

أو

private string Password { set; }

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

هل يستخدم أي شخص خاصية خاصة في C # لأي سبب من الأسباب أم أنه مجرد واحد من تلك التركيبات الممكنة تقنيًا - رغم أنه نادر الاستخدام - في التعليمة البرمجية الفعلية؟

إضافة

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

  • عندما تحتاج الحقول الخاصة للتحميل
  • عندما تحتاج الحقول الخاصة إلى منطق إضافي أو يتم حساب القيم
  • بما أن الحقول الخاصة قد يصعب تصحيحها
  • من أجل "تقديم عقد لنفسك"
  • لتحويل / تبسيط خاصية مكشوفة كجزء من التسلسل
  • التفاف المتغيرات العالمية لاستخدامها داخل صفك

ربما هناك حالة استخدام مع الطبقات المتداخلة / الموروثة أو ربما حيث يمكن أن تحتوي على / تعيين المنطق بدلا من مجرد إعطاء قيمة الخاصية

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

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

في حالة شبه متصلة (على الرغم من اختلافها عن سؤالك) ، فأنا كثيرا ما أستخدم المستأجرين الخاصين في العقارات العامة:

public string Password 
{
    get; 
    private set;
}

يمنحك ذلك أداة إعلانية عامة ، ولكنه يحافظ على خصوصية الإعدادات.


أستخدم خصائص خاصة لتقليل التعليمات البرمجية للوصول إلى الخصائص الفرعية التي غالباً ما تستخدم.

    private double MonitorResolution
    {
        get { return this.Computer.Accesories.Monitor.Settings.Resolution; }
    }

من المفيد إذا كان هناك العديد من الخصائص الفرعية.


أنا استخدامها في التسلسل ، مع أشياء مثل DataContractSerializer أو protobuf-net التي تدعم هذا الاستخدام (لا XmlSerializer ). من المفيد إذا كنت بحاجة إلى تبسيط كائن كجزء من التسلسل:

public SomeComplexType SomeProp { get;set;}
[DataMember(Order=1)]
private int SomePropProxy {
    get { return SomeProp.ToInt32(); }
    set { SomeProp = SomeComplexType.FromInt32(value); }
}

أنا استخدمها بين الحين والآخر. يمكن أن تسهل تصحيح الأخطاء عندما يمكنك بسهولة وضع نقطة توقف في الخاصية أو يمكنك إضافة بيان تسجيل الخ.

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


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

سبب آخر للممتلكات الخاصة على الحقول هو أن الخصائص الخاصة أسهل بكثير من الحقول الخاصة. أرغب في كثير من الأحيان في معرفة أشياء مثل "يتم تعيين هذا الحقل بشكل غير متوقع ؛ من هو المتصل الأول الذي يحدد هذا الحقل؟" ويكون الأمر أسهل إذا كنت تستطيع وضع نقطة توقف على أداة التحديد والضغط. يمكنك وضع تسجيل الدخول هناك. يمكنك وضع مقاييس الأداء هناك. يمكنك وضع تدقيقات التناسق التي تعمل في بناء التصحيح.

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


الاستخدام الوحيد الذي يمكنني التفكير فيه

private bool IsPasswordSet 
{ 
     get
     {
       return !String.IsNullOrEmpty(_password);
     }
}

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

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


شيء واحد أقوم به طوال الوقت هو تخزين متغيرات "العمومية" / ذاكرة التخزين المؤقت في HttpContext.Current

private static string SomeValue{
  get{
    if(HttpContext.Current.Items["MyClass:SomeValue"]==null){
      HttpContext.Current.Items["MyClass:SomeValue"]="";
    }
    return HttpContext.Current.Items["MyClass:SomeValue"];
  }
  set{
    HttpContext.Current.Items["MyClass:SomeValue"]=value;
  }
}

ومن المنطقي تماما عندما يكون هناك منطق المرتبطة مجموعة الممتلكات أو الحصول عليها (أعتقد التهيئة البطيئة) ويتم استخدام الخاصية في أماكن قليلة في الفصل.

إذا كان مجرد مجال دعم مستقيم؟ لا شيء يتبادر إلى الذهن كسبب وجيه.





access-modifiers