सार्वजनिक सदस्य चर का उपयोग करने के बजाय खाली सेट गुण क्यों हैं?

Question

संभव डुप्लिकेट:
C#: Public Fields versus Automatic Properties

डुप्लिकेट? मुझे नहीं लगता कि:
इस सवाल के रूप में "क्यों उपयोग गुण के बजाय सार्वजनिक क्षेत्र" नहीं में ही है। एक निर्दिष्ट गेटटर और सेटर वाला एक संपत्ति सार्वजनिक क्षेत्र की तुलना में बहुत अलग है। मेरा सवाल था, एक संपत्ति बिना गेटटर और सेटर, कोई अलग है।

खाली गेटर्स और सेटर्स रखने की हाल की क्षमता के साथ, सार्वजनिक सदस्य चर घोषित करने के बजाय उन्हें उपयोग करने का क्या फायदा है?

उदाहरण:

public string MyProperty 
{ 
    get; 
    set; 
} 

बनाम:

public string MyProperty; 

Answer 1

एक शब्द: विरासत।

गुण विरासत योग्य नहीं हैं जबकि फ़ील्ड नहीं हैं। आप विरासत में फ़ील्ड का उपयोग कर सकते हैं, लेकिन उन्हें वर्चुअल बनाकर अपने व्यवहार को बदल नहीं सकते हैं।

तो जैसा:

public class Foo { 
    public virtual int MyField = 1; // Nope, this can't 

    public virtual int Bar {get; set; } 
} 

public class MyDerive : Foo { 
    public override MyField; // Nope, this can't 

    public override int Bar { 
    get { 
     //do something; 
    } 
    set; } 
} 

संपादित करें: विरासत का तथ्य यह है इसके अलावा, अंक अन्य उत्तर (दृश्यता) की तरह में बताया भी खेतों से अधिक संपत्तियों की एक बड़ी लाभ कर रहे हैं।

public string MyProperty { get; private set; } 

कुछ मैं काफी एक बहुत का उपयोग करें:

Answer 2

एक बात आप गुण है कि आप क्षेत्रों के साथ ऐसा नहीं कर सकते के साथ कर सकते या तो सेटर या गेटर के लिए सीमा दृश्यता है।

और कुछ (अधिक शक्तिशाली) आप फ़ील्ड के साथ नहीं कर सकते हैं उन्हें एक इंटरफ़ेस के अंदर परिभाषित किया जाता है।

public interface MyInterface 
{ 
    string MyProperty { get; } 
} 

ध्यान दें कि आप यहाँ एक सेटर की आवश्यकता नहीं है: आप एक अंतरफलक आवश्यक होता है कि कक्षाओं में लागू करने के लिए एक निश्चित संपत्ति है रखना चाहते हैं। यह निर्धारित करने के लिए कक्षाओं को लागू करने के लिए पूरी तरह से तैयार है कि उन्हें MyProperty कैसे सेट करना चाहिए।

Answer 3

इंटरफेस में फ़ील्ड्स का खुलासा नहीं किया जा सकता है। और कक्षा बदलने के हस्ताक्षर और इंटरफ़ेस के बिना, यदि आवश्यक हो तो ऑटो-प्रॉपर्टी को किसी भी समय "सामान्य" संपत्ति में बदला जा सकता है।

सामान्य रूप से, फ़ील्ड को कार्यान्वयन विवरण माना जाता है, जो कोड के भविष्य के संस्करणों में बदल सकता है। इसलिए, आपको भविष्य में आंतरिक परिवर्तनों के लिए रास्ता खोलने के तरीकों और गुणों के माध्यम से डेटा का खुलासा करना चाहिए जो कक्षा का उपयोग करके कोड को प्रभावित नहीं करता है।

Answer 4

विचार ऑब्जेक्ट, राज्य, भ्रष्टाचार से बचने और कोड को कॉल करके दुरुपयोग से बचने का विचार है।

Answer 5

कोई प्रॉपर्टी एक सरल सार्वजनिक क्षेत्र पर आप कई फायदे देता है:

• आप नियंत्रित कर सकते हैं कि प्रॉपर्टी केवल पढ़ने के लिए है-केवल लिखते हैं, या पढ़ने/लिखने
• आप वास्तविक क्रियान्वयन छिपा कर सकते हैं

Answer 6

जब डेटा बाइंडिंग का उपयोग कर (जैसे ASP.NET में), आप गुण का उपयोग करना होगा (क्षेत्रों के साथ काम नहीं करता है) (शायद सेटर में आप और अधिक करने के लिए सिर्फ एक मान सेट की तुलना में चाहते हैं) Y कहां गुणों के साथ गुणों को ध्वजांकित कर सकते हैं जो सदस्यों पर उपलब्ध नहीं हैं। ऐसे गुण हैं जो केवल डेटाकंट्रैक्ट नेमस्पेस के फ़ील्ड पर लागू होते हैं जो क्रमबद्धता को प्रभावित करते हैं, विशेषता फ़ील्ड पर लागू नहीं की जा सकती है।

मान्य रूप से, इन विशेषताओं को सदस्यों पर उपयोग करने से तकनीकी रूप से कुछ भी नहीं रोक रहा है, लेकिन फिर भी वे केवल संपत्तियों पर काम करते हैं।

Answer 7

तंग युग्मन दिमाग में आता है। सार्वजनिक क्षेत्रों का उपयोग गुणों के उपयोग से उपलब्ध अमूर्त परत की परत को हटा देता है। निजी क्षेत्रों और संपत्तियों का उपयोग अन्य वर्गों से कार्यान्वयन को छुपाता है और जब भी कोई बदलाव आवश्यक होता है तो उन्हें (बाहरी कक्षाएं) को अपनाने में मदद मिलती है।

इसके अलावा, ध्यान रखें कि आप auto-implemented properties जो आप के लिए समर्थन क्षेत्र बनाने के लिए के बजाय यदि आप स्वयं अपनी कक्षा पर प्रत्येक प्रॉपर्टी के लिए समर्थन (निजी) क्षेत्र बनाने के लिए होने संकलक का कारण बनता है की बात कर रहे में रहते हैं।