2010-07-17 7 views
9

एक तरफ, मुझे पता है कि गुण की सलाह दी जाती उपयोग निम्न उदाहरण में की तरह एक समर्थन क्षेत्र के लिए, यह है:गुण बैकिंग फ़ील्ड - इसके लिए क्या अच्छा है?

private int m_Capacity; 

    public int Capacity 
    { 
     get { return m_Capacity > 0 ? m_Capacity : -666; } 
     set { m_Capacity = value; } 
    } 

दूसरी ओर, क्या लाभ मैं ऊपर के उदाहरण का उपयोग करने से मिलता है निम्न उदाहरण में क्षेत्र को त्यागकर और सभी प्रयोजनों के लिए केवल संपत्ति का उपयोग कर, की तरह:

public int Capacity 
    { 
     get { return Capacity > 0 ? Capacity : -666; } 
     set { Capacity = value; } 
    } 

क्या नियमित (गैर ऑटो कार्यान्वित) गुणों के लिए एक समर्थन क्षेत्र का उपयोग कर के बारे में अच्छा है?

+6

क्या आपको लगता है कि आपके दूसरे उदाहरण परिणाम StackOverflowExceptions में नहीं हैं? क्या आपने इसे सही लिखा है? आप वर्तमान में संपत्ति के भीतर से संपत्ति का संदर्भ दे रहे हैं। –

+1

आप सभी सही हैं। मैंने यह नहीं सोचा और न ही मैंने कोड चलाया। – galbarm

+2

@ एलेक्स हम्फ्री: .. संपत्ति के भीतर ही संपत्ति के भीतर ही संपत्ति के भीतर ही .. – maxwellb

उत्तर

21

आप ऐसा करते हैं:

public int Capacity 
{ 
    get { return Capacity > 0 ? Capacity : -666; } 
    set { Capacity = value; } 
} 

फिर अपने कोड एक अनंत प्रत्यावर्तन करना होगा। यह कभी काम नहीं करेगा। ऐसा इसलिए है क्योंकि क्षमता के लिए गेटर खुद का संदर्भ दे रहा है। सेटर के लिए वही बात होती है।

जब तक आप स्वत: गुण का उपयोग कर रहे हैं, आप एक समर्थन क्षेत्र की जरूरत

+1

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

2

अधिकतर क्योंकि आपको स्टैक ओवरफ्लो मिलेगा।

+0

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

+0

क्या यह रिशेर्पर है जो कॉल को रिकर्सिव होने पर बाएं हाशिए में थोड़ा सा प्रतीक डालता है? मैं हमेशा इसे देखता हूं, लेकिन मुझे यकीन नहीं है कि ऐसी चीजें आर # या वीएस हैं या नहीं। –

+0

शायद रिशेर्पर; मैंने स्टॉक वीएस में ऐसा कुछ भी नहीं देखा है। – cHao

3

अगर तुम कभी नहीं बल्कि 'कामयाब' मूल्य आप क्षमता से प्राप्त की तुलना में, m_Capacity के वास्तविक मूल्य का उपयोग करने की जरूरत है स्पष्ट निजी memberid उपयोगी है संपत्ति,

संपादित करें: अन्य पोस्ट सही ढंग से वाक्यविन्यास त्रुटि को इंगित करते हैं। मुझे इसका भी उल्लेख करना चाहिए था, लेकिन मैंने इसे अनदेखा किया और बस अपने प्रश्न का उत्तर देने की कोशिश की, जो स्वचालित गुणों के बारे में प्रतीत होता था

+0

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

+0

इसे उत्तर दिया जाना चाहिए। वर्तमान स्वीकार्य उत्तर केवल यह कहता है कि आपको एक संपत्ति की आवश्यकता है, लेकिन क्यों नहीं * इसकी आवश्यकता है, जो ओपी के प्रश्न का उत्तर देगी। –

2

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

+0

को "वाक्यविन्यास चीनी" भी कहा जाता है। –

1

बैकिंग फ़ील्ड encapsulation की अवधारणा का समर्थन करते हैं।

Encapsulation आपको बाद में अपने इंटरफेस को बदले बिना कक्षा के कार्यान्वयन विवरण को बदलने की अनुमति देता है।

इसका मतलब है कि पब्लिक क्लास सदस्य होने के बजाय गेटर्स और सेटर्स के साथ बैकिंग फ़ील्ड होने से भविष्य में डेवलपर्स या भविष्य के स्वयं के लिए आपका कोड अधिक मजबूत और/या पठनीय हो जाएगा।

संबंधित मुद्दे