इंटरफेस में C # प्रॉपर्टी की अनुमति क्यों देता है?

Question

C # में, निम्न कोड मान्य है

interface I{
    int property{get;set;}
}

जो मेरे लिए कोई मतलब नहीं है। यह इंटरफेस के सबसे महत्वपूर्ण सिद्धांतों में से एक को तोड़ने के लिए लगता है: राज्य की कमी (दूसरे शब्दों में, कोई क्षेत्र नहीं)। क्या संपत्ति एक निजी क्षेत्र का निर्माण नहीं करती है? कि इंटरफेस के लिए वास्तव में बुरा नहीं होगा?

Comments

इंटरफ़ेस कार्यान्वयन के सिद्धांतों में से एक राज्य की कमी है ? मेरे लिए, एक इंटरफ़ेस एक अनुबंध को परिभाषित करने का एक तरीका है, अर्थात यदि कोई वर्ग ऐसे इंटरफ़ेस को लागू करता है, तो इसमें अनुबंध में परिभाषित सभी विधियां और गुण हैं।

— फ्लोरियन मार्गाइन

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

— डोभाल

@FlorianMargaine निश्चित रूप से एक अनुबंध की अवधारणा इंटरफेस का सबसे महत्वपूर्ण सिद्धांत है, लेकिन राज्य की कमी भी महत्वपूर्ण है। यह इसे एक अमूर्त वर्ग से अलग रखने में मदद करता है। जावा 8 में IE यह अंतरापृष्ठ और अमूर्त वर्ग के बीच एकमात्र प्रमुख अंतर है।

— मोनिका

क्योंकि इसका कोई क्षेत्र नहीं है। देखें कि C # इंटरफ़ेस में फ़ील्ड क्यों नहीं हो सकते?

@ डोभाल: यह स्वाभाविक है कि एक इंटरफ़ेस ऐसे तरीकों की घोषणा करता है, लेकिन ऐसा नहीं है कि यह उन्हें लागू करता है।

— जियोर्जियो

Answer 1

मुझे लगता है कि भ्रामक हिस्सा यह है कि यदि आप int Property { get; set; }एक वर्ग के अंदर लिखते हैं , तो यह एक ऑटो-संपत्ति है जिसका निहित समर्थन क्षेत्र है।

लेकिन अगर आप एक इंटरफ़ेस में एक ही बात लिखते हैं, तो यह ऑटो-प्रॉपर्टी नहीं है , यह सिर्फ यह घोषणा करता है कि प्रॉपर्टी इंटरफ़ेस का हिस्सा है और यह कि किसी भी प्रकार के इंटरफ़ेस को लागू करने के लिए उस संपत्ति को शामिल करना होगा (ऑटो-प्रॉपर्टी के रूप में या नहीं ), लेकिन यह समर्थन क्षेत्र नहीं बनाता है।

अंतर देखने का एक तरीका लिखना है int Property { get; }: यह एक इंटरफ़ेस में मान्य है और एक संपत्ति की घोषणा करता है जिसमें केवल एक गेटर है, लेकिन कोई सेटर नहीं है। लेकिन यह एक वर्ग में संकलित नहीं होगा (जब तक कि आप C # 6.0 का उपयोग नहीं कर रहे हैं), क्योंकि ऑटो-प्रॉपर्टी में एक सेटर होना आवश्यक है।

Answer 2

संपत्ति को परिभाषित करना जैसा आपने दिखाया है, परिभाषित करने के तरीकों int GetProperty()और के समान है void SetProperty(int i)। गुण C # में शक्तिशाली शॉर्ट-हैंड हैं।

एक संपत्ति C # का निजी क्षेत्र नहीं बनाती है। auto-propertyउदाहरण के लिए, यह एक डिफ़ॉल्ट कार्यान्वयन है public string MyString { get; set;}- हालांकि, एक संपत्ति जो getविधि में कस्टम तर्क को परिभाषित करती है, एक अंतर्निहित निजी क्षेत्र उत्पन्न नहीं करती है।

अंत में, जैसा कि इंटरफेस सार्वजनिक एपीआई के साथ संबंध है, अगर एक निजी क्षेत्र पर निर्भर इंटरफेस संपत्ति के कार्यान्वयन - निहित या अन्यथा, इससे क्या फर्क पड़ेगा? यह परवाह किए बिना इंटरफ़ेस के उपभोक्ताओं से छिपा हुआ है।

Comments

आह ... मुझे नहीं पता था कि यह केवल ऑटो-संपत्तियों के लिए होता है, और जब से आपको इसे ओवरराइड करना पड़ता है, यह समझ में आता है। लेकिन अगर इंटरफ़ेस एक आंतरिक निजी चर बनाने के लिए था, तो कार्यान्वयनकर्ताओं के पास इसका उपयोग नहीं होगा - एक स्पष्ट समस्या।

— मोनिका

यदि आप किसी संपत्ति को C # इंटरफ़ेस में परिभाषित करते हैं, तो उस संपत्ति का कार्यान्वयन कार्यान्वयन वर्ग पर छोड़ दिया जाता है - वे इसे एक ऑटो-संपत्ति बना सकते हैं, या कस्टम तर्क को परिभाषित कर सकते हैं जैसा कि वे फिट देखते हैं। इंटरफ़ेस में कोई फ़ील्ड नहीं जोड़ी गई है ।

— NWARD

Answer 3

गुण हैं तरीकों! एक बैकिंग फ़ील्ड उस वर्ग में जोड़ा जाएगा जो इंटरफ़ेस को लागू करता है (या तो मैन्युअल रूप से या ऑटो-संपत्ति के माध्यम से)।

Comments

कभी-कभी कोई बैकिंग फ़ील्ड नहीं होगा। हालांकि यह एक गेट और सेट दोनों को परिभाषित करने के लिए दुर्लभ होगा और इसके लिए एक बैकिंग क्षेत्र नहीं होगा।

— स्टीफन

+1 गुण विधियां हैं! हाँ! मुझे प्रॉपर्टीमेथोड लिखना पसंद है लेकिन कोड-समीक्षा करने वाले सह-कार्यकर्ता इसे इस तरह से नहीं देखते हैं और हम वास्तव में हमारे कार्यक्रमों में कुछ अच्छे अभिव्यंजक एन्कैप्यूलेशन के लिए अवसरों को याद करते हैं।

— राडारबॉब

उन "संपत्ति विधियों" को त्वरित होना चाहिए, जैसे कोई DB लुकअप या कुछ भी नहीं। एक निहित अनुबंध है कि संपत्ति की पहुंच तेज है, प्राप्त करें * विधियाँ धीमी हो सकती हैं।

— ट्रे मैक