केवल .NET में कोई संबंधित फ़ील्ड के साथ गुणों का उपयोग करने के नुकसान?

Question

मेरे पास कक्षाएं हैं जिनके पास केवल सार्वजनिक ग्राहक की तरह स्वचालित गुण हैं {get; सेट;}। वे सार्वजनिक हैं क्योंकि उन्हें कक्षा के बाहर पहुंचाया जाता है। उन्हें कक्षा के अंदर भी पहुंचा जा सकता है। वे अच्छे encapsulation और बेहतर डीबगिंग प्रदान करते हैं। अगर मुझे यह जानने की ज़रूरत है कि कौन इसे एक्सेस कर रहा है और कब मैं एक ब्रेकपॉइंट डाल सकता हूं।

मेरा प्रश्न यह है कि केवल संबंधित क्षेत्रों के साथ गुणों का उपयोग करने के नुकसान क्या हैं? मैं सेटटर या गेटटर निजी, आंतरिक .. आदि बना सकता हूं जिसका मतलब है कि जब भी आवश्यकता हो तो मुझे इसे स्कूप करने की लचीलापन भी होती है।

Answer 1

क्रमबद्धता - आप बड़ा समस्या है अगर आप कुछ मान्यता/इवेंट/आदि जोड़ने के लिए उदाहरण के लिए बाद में एक "नियमित" संपत्ति के लिए अपनी संपत्ति को बदलने की आवश्यकता - sinc BinaryFormatter फ़ील्ड नाम का उपयोग करता है। और आप इसे डुप्लिकेट नहीं कर सकते हैं, क्योंकि फ़ील्ड नाम कंपाइलर जेनरेट्स को कानूनी सी # के रूप में नहीं लिखा जा सकता है।

इसके बजाय अनुबंध-आधारित धारावाहिक को देखने का एक अच्छा कारण कौन सा है। अधिक जानकारी के लिए this blog entry देखें।

Answer 2

सरल गुणों के लिए कोई नुकसान नहीं है। कंपाइलर आपके लिए बैकिंग फ़ील्ड बनाता है। यह blog entry बताता है कि संकलक स्वचालित रूप से कार्यान्वित गुणों का इलाज कैसे करता है।

Answer 3

बात यह है कि एक संबंधित फ़ील्ड है। आप इसे नहीं देखते हैं क्योंकि संकलक इसे आपके लिए बनाता है। स्वचालित गुण क्षेत्र बनाने के लिए सिंटैक्टिक चीनी या शॉर्टेंड रास्ता हैं।

Answer 4

आप नहीं बना सकते हैं वास्तव में केवल संपत्ति पढ़ते हैं, क्योंकि आपको दोनों सेटर और गेटर को परिभाषित करना होगा। आप बाहर से छद्म-पाठक संपत्ति प्राप्त करने के लिए केवल निजी सेटटर का उपयोग कर सकते हैं।

अन्यथा, जैसा ऊपर बताया गया है कि कोई अन्य नुकसान नहीं है।

Answer 5

कोई बड़ी चीजें नहीं। बस किनारे के मामलों जैसे कि आपको किसी विधि को संपत्ति पारित करने की आवश्यकता है जहां पैरामीटर संदर्भ (ref या out) द्वारा पारित किया गया है, जो किसी संपत्ति के साथ संभव नहीं है (क्योंकि आंतरिक रूप से, वे केवल कंपाइलर द्वारा लागू_Property/set_Property विधियां हैं , किसी विशेष प्रकार के विशेष क्षेत्र नहीं) और इसके लिए आपको एक स्पष्ट निजी समर्थन क्षेत्र की आवश्यकता होगी।

संपादित करें: ओह, और '' गुणों को दूसरी बार, जो वास्तव में काफी आम है।

Answer 6

आप प्राप्त और/या सेट accessors में किसी भी विशिष्ट तर्क प्रदर्शन करने की जरूरत नहीं है, वहाँ कोई नुकसान ...

Answer 7

मैं कहता हूं कि वे एक कोड पठनीयता दृष्टि से बुरा कर रहे हैं है। सिंटेक्स चीनी कोड लिखने के लिए अच्छा है लेकिन कोड पढ़ने के लिए भयानक है। डेवलपर्स के रूप में हम जिस कोड को पीछे छोड़ते हैं, वह आखिरकार कुछ गरीब डेवलपर द्वारा विरासत में प्राप्त किया जाएगा जिसे हमने जो किया और कोड में क्या चल रहा है, उसे समझना होगा। जब मैं एक ही संरचना के लिए एक स्थापित वाक्यविन्यास होता हूं तो मैं वास्तव में कीस्ट्रोक को बचाने के लिए एक भाषा बदलने के खिलाफ हूं।

Answer 8

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

private bool _flag = true; 
public bool Flag 
{ 
    get { return _flag; } 
    set { _flag = value; } 
} 

इससे यह स्पष्ट हो गया कि संपत्ति का डिफ़ॉल्ट मूल्य क्या है।

स्वचालित गुणों के साथ, आपको यह जानना होगा कि विभिन्न प्रकारों के लिए डिफ़ॉल्ट मान क्या हैं (उदा। बूल के लिए झूठा)। आप डिफ़ॉल्ट मान के लिए संपत्ति नहीं करना चाहते हैं आप निर्माता में यह प्रारंभ करने के लिए है:

class MyClass 
{ 
    public bool Flag { get; set; } 
    public MyClass() 
    { 
    Flag = true; 
    } 
} 

इसका मतलब यह है, तो आप एक निर्माता लागू करने के लिए है, तो आप गैर डिफ़ॉल्ट करने के लिए अपने गुण को प्रारंभ करना चाहते हैं मूल्य या यदि कोई संपत्ति किसी संदर्भ प्रकार (वर्ग) का है।

लेकिन जैसा कि मैंने लिखा है, मैं वास्तव में इसे नुकसान के रूप में नहीं सोचता, केवल कुछ जो आपको जानना है। BinaryFormatter साथ