c# - स्वचालित गुण बनाम सार्वजनिक क्षेत्र




class properties (7)

हमें अक्सर बताया जाता है कि हमें बाहरी क्षेत्रों में खेतों को उजागर करने के बजाय कक्षा क्षेत्रों के लिए गेटर और सेटर विधियों (सी # में गुण) बनाकर encapsulation की रक्षा करनी चाहिए।

लेकिन कई बार ऐसे क्षेत्र होते हैं जब कोई मूल्य मूल्य रखने के लिए होता है और उसे प्राप्त करने या सेट करने के लिए किसी भी गणना की आवश्यकता नहीं होती है। इनके लिए हम सभी इस नंबर को करेंगे:

public class Book
{
    private string _title;

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

खैर, मुझे एक कबुलीजबाब है, मैं यह सब लिख नहीं सकता था (वास्तव में, इसे लिखना नहीं था, इसे देखना था), इसलिए मैं बदमाश हो गया और सार्वजनिक क्षेत्रों का इस्तेमाल किया।

फिर सी # 3.0 आता है और मुझे लगता है कि उन्होंने स्वचालित गुण जोड़े हैं:

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

जो कि कठिन है, और मैं इसके लिए आभारी हूं, लेकिन वास्तव में, सार्वजनिक क्षेत्र बनाने से इतना अलग क्या है?

public class Book
{
    public string Title;
}

एक संबंधित प्रश्न में मैंने कुछ समय पहले, जेफ के ब्लॉग पर एक पोस्टिंग का एक लिंक था, जिसमें कुछ अंतर बताए गए थे।

गुण बनाम सार्वजनिक चर

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

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

एक क्षेत्र public बनाने में कुछ भी गलत नहीं है। लेकिन private क्षेत्रों के साथ getter/setter बनाने की याद रखना कोई encapsulation नहीं है। आईएमओ, यदि आपको किसी Property की अन्य सुविधाओं की परवाह नहीं है, तो आप इसे public भी कर सकते हैं।


एक बड़ा अंतर जिसे अक्सर अनदेखा किया जाता है और किसी अन्य उत्तर में इसका उल्लेख नहीं किया जाता है: ओवरराइडिंग । आप गुण वर्चुअल घोषित कर सकते हैं और उन्हें ओवरराइड कर सकते हैं जबकि आप सार्वजनिक सदस्य फ़ील्ड के लिए ऐसा नहीं कर सकते हैं।


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

सीएलआर डीबगर डेटा ब्रेक पॉइंट्स का समर्थन नहीं करता है (अधिकांश मूल डिबगर्स करते हैं)। इसलिए कक्षा में किसी विशेष क्षेत्र के पढ़ने या लिखने पर ब्रेक पॉइंट सेट करना संभव नहीं है। यह कुछ डीबगिंग परिदृश्यों में बहुत सीमित है।

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


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

यदि आप केवल एक सार्वजनिक विशेषता के साथ जाते हैं तो आपके पास कम लचीलापन होगा।

अनुबंध तोड़ने के बिना अतिरिक्त लचीलापन गुणों का उपयोग करने के बारे में मेरे लिए सबसे महत्वपूर्ण है, और जब तक मुझे वास्तव में लचीलापन की आवश्यकता नहीं होती है, ऑटो-पीढ़ी सबसे अधिक समझ में आता है।


यह संस्करण और एपीआई स्थिरता के बारे में सब कुछ है। संस्करण 1 में कोई फर्क नहीं पड़ता है, लेकिन बाद में, यदि आप तय करते हैं कि आपको इसे किसी संस्करण को संस्करण 2 में जांचने के लिए किसी प्रकार की त्रुटि के साथ बनाने की आवश्यकता है, तो आपको अपने एपीआई को बदलने की ज़रूरत नहीं है- कोई भी कोड परिवर्तन नहीं, कहीं भी, अन्य संपत्ति की परिभाषा।


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





automatic-properties