सी # 3.0 ऑटो-गुण - उपयोगी या नहीं?

नोट: यह पोस्ट किया गया था जब मैं सी # शुरू कर रहा था। 2014 के ज्ञान के साथ, मैं सचमुच कह सकता हूं कि ऑटो-प्रॉपर्टी सी # भाषा के साथ होने वाली सबसे अच्छी चीजों में से एक हैं।

मैं निजी और सार्वजनिक क्षेत्र का उपयोग कर सी # में अपनी गुण बनाने के लिए उपयोग किया जाता हूं:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

अब, .NET 3.0 के साथ, हमें ऑटो-गुण प्राप्त हुए:

public string Title { get; set; }

मुझे पता है कि यह एक दार्शनिक/व्यक्तिपरक प्रश्न है, लेकिन क्या इन क्षेत्रों के लिए कोड की पांच पंक्तियों को सहेजने के अलावा इन ऑटो-गुणों का उपयोग करने का कोई कारण है? मेरी निजी पकड़ यह है कि वे गुण मुझसे छिपा रहे हैं, और मैं काले जादू का बड़ा प्रशंसक नहीं हूं।

वास्तव में, छुपा निजी क्षेत्र डीबगर में भी दिखाई नहीं देता है, जो कि तथ्य यह है कि प्राप्त/सेट फ़ंक्शन कुछ भी नहीं करते हैं। लेकिन जब मैं वास्तव में कुछ गेटर/सेटर लॉजिक को लागू करना चाहता हूं, तो मुझे निजी/सार्वजनिक जोड़ी का उपयोग करना होगा।

मुझे लाभ मिलता है कि मैं बाद में गेटर/सेटर लॉजिक को बदलने की क्षमता खोने के बिना बहुत सारे कोड (एक बनाम छः लाइनों) को बचाता हूं, लेकिन फिर मैं बिना किसी सार्वजनिक क्षेत्र "सार्वजनिक स्ट्रिंग शीर्षक" को घोषित करके कर सकता हूं {प्राप्त करने की आवश्यकता; सेट; } ब्लॉक, इस प्रकार अधिक कोड भी बचा रहा है।

तो, मैं यहाँ क्या याद कर रहा हूँ? वास्तव में कोई भी ऑटो-प्रॉपर्टी का उपयोग क्यों करना चाहेगा?

0
ro fr bn
"मेरी व्यक्तिगत पकड़ यह है कि वे गुण मुझसे छिपा रहे हैं, और मैं काले जादू का बड़ा प्रशंसक नहीं हूं।" है ना? आप जानते हैं कि संकलक हर समय आपके से एक टन छुपाता है, है ना? जब तक आप असेंबली लिख रहे हों (या अधिक सटीक रूप से, आपके कोड के लिए वास्तविक 1 और 0 का), तो आप जो भी लिखते हैं वह आपके द्वारा सामान छिपा रहा है।
जोड़ा लेखक Charles Boyung, स्रोत

2 उत्तर

मैं व्यक्तिगत रूप से ऑटो गुणों से प्यार करता हूँ। कोड की लाइनों को सहेजने में क्या गलत है? अगर आप गेटर्स या सेटर्स में सामान करना चाहते हैं, तो उन्हें बाद में सामान्य गुणों में बदलने में कोई समस्या नहीं है।

जैसा कि आपने कहा था कि आप खेतों का उपयोग कर सकते हैं, और यदि आप उन्हें तर्क जोड़ना चाहते हैं तो आप उन्हें गुणों में परिवर्तित कर देंगे। लेकिन यह प्रतिबिंब (और संभवतः कहीं और?) के किसी भी उपयोग के साथ समस्याएं पेश कर सकता है।

इसके अलावा गुण आपको गेटटर और सेटर के लिए अलग-अलग एक्सेस स्तर सेट करने की अनुमति देते हैं, जिन्हें आप किसी फ़ील्ड से नहीं कर सकते हैं।

मुझे लगता है कि यह var कीवर्ड जैसा ही है। व्यक्तिगत वरीयता का मामला।

0
जोड़ा

गुणों के बजाय फ़ील्ड का उपयोग करने के लिए तीन बड़े डाउनसाइड्स हैं:

  1. आप किसी क्षेत्र में डेटाबेस नहीं कर सकते हैं जबकि आप किसी संपत्ति के लिए
  2. कर सकते हैं
  3. यदि आप किसी फ़ील्ड का उपयोग करना बंद कर देते हैं, तो आप बाद में (आसानी से) उन्हें किसी संपत्ति में बदल नहीं सकते
  4. कुछ विशेषताएं हैं जिन्हें आप किसी ऐसे प्रॉपर्टी में जोड़ सकते हैं जिसे आप किसी फ़ील्ड में नहीं जोड़ सकते
0
जोड़ा
"यदि आप किसी फ़ील्ड का उपयोग करना बंद कर देते हैं, तो आप बाद में (आसानी से) किसी संपत्ति में नहीं बदल सकते हैं", क्षमा करें, लेकिन क्यों?
जोड़ा लेखक Homam, स्रोत
@ होमाम मुख्य रूप से, आपके क्षेत्र पर प्रतिबिंब का उपयोग करने वाला कोई भी उपभोक्ता कोड तोड़ देगा, क्योंकि उन्हें FieldInfo का उपयोग PropertyInfo से स्विच करना होगा।
जोड़ा लेखक WCWedin, स्रोत