सार्वजनिक चर के गुण क्यों पसंद करते हैं?

Question

अन्य एक सेटर में सैनिटी चेक वैल्यू करने में सक्षम होने के कारण सार्वजनिक चर के गुणों को प्राथमिकता देने के लिए एक और अंतर्निहित कारण है?

Answer 1

हमारे पास पहले यह विषय था लेकिन मुझे अब कुछ भी नहीं मिला।

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

यह खराब है क्योंकि यह संभावित रूप से बहुत सारा पैसा खर्च करता है।

शुरुआत से गुणों का उपयोग इस समस्या से बचाता है। यह कोड के लिए भी गिना जाता है जो लाइब्रेरी का हिस्सा नहीं है। क्यूं कर? क्योंकि आप कभी नहीं जानते: कोड (भले ही अत्यधिक डोमेन-विशिष्ट!) उपयोगी साबित हो सकता है ताकि आप इसे लाइब्रेरी में दोबारा प्रतिक्रिया दे सकें। यदि आप पहले से ही सार्वजनिक/संरक्षित क्षेत्रों के स्थान पर गुणों का उपयोग कर रहे हैं तो यह रिफैक्टरिंग प्रक्रिया स्पष्ट रूप से बहुत आसान हो गई है।

इसके अतिरिक्त, सार्वजनिक गुण लेखन, सी # 3.0, क्योंकि आप बस ऑटो कार्यान्वित गुण का उपयोग कर सकते में आसान है, आप काफी कोड का एक सा बचत:

public DataType MyProperty { get; set; } 

आवश्यक समर्थन क्षेत्र और गेटर को लागू करेगा/सेटर आपके लिए कोड

मैं एक व्यक्तिगत नोट जोड़ूंगा: इस संबंध में .NET का व्यवहार कुछ हद तक आलसी है। कंपाइलर केवल सार्वजनिक क्षेत्रों को फ्लाई पर गुणों में बदल सकता है, इस प्रकार समस्या से परहेज कर सकता है। वीबी 6 ने पहले से ही COM-exposed कक्षाओं के लिए यह किया है और मुझे VB.NET और C# के लिए बिल्कुल ऐसा कोई कारण नहीं दिखता है। शायद कंपाइलर टीमों (जेरेड?) पर कोई इस पर टिप्पणी कर सकता है।

Answer 2

Jeff Atwood has blogged about it:

वहाँ बिल्कुल के रूप में ऊपर दर्शाया एक छोटी सी संपत्ति बनाने के लिए वैध कारण हैं:

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

यह एक शर्म की बात है कि चर और गुणों के बीच इतनी अर्थहीन घर्षण है; ज्यादातर समय वे एक ही चीज करते हैं। Kevin Dente नई वाक्य रचना का एक सा है कि हम दोनों दुनिया के सर्वश्रेष्ठ देना होगा प्रस्तावित:

public property int Name; 

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

Answer 3

गुणों का उपयोग आपके कोड को अधिक ऑब्जेक्ट उन्मुख बनाता है। सदस्य चर सार्वजनिक बनाकर, आप अपना कार्यान्वयन उजागर कर रहे हैं।

इसके अलावा इस link सी # के प्रोग्रामिंग गाइड

Answer 4

से देख भविष्य में एक संपत्ति के लिए एक क्षेत्र परिवर्तित करने से एक तोड़ने परिवर्तन माना जाता है। क्षेत्रों को कक्षाओं के कार्यान्वयन के विवरण माना जाता है और उन्हें सार्वजनिक रूप से ब्रेक इनकैप्यूलेशन का खुलासा किया जाता है।

Answer 5

यदि आप एक बंद वातावरण में काम करते हैं - आप एक एसडीके विकसित नहीं करते हैं, तो सभी वर्गों का उपयोग एक ही परियोजना ढांचे के भीतर किया जाता है - इसमें कोई फर्क नहीं पड़ता।

सामान्य तर्क यह है कि "भविष्य में आपको मूल्यों पर कुछ जांच करने की आवश्यकता हो सकती है, इसलिए गुणों के साथ यह आसान है"। मैं इसे बिल्कुल खरीद नहीं पा रहा हूं।

सार्वजनिक क्षेत्रों का उपयोग करना अधिक पठनीय, कम सजावट और उपयोग करने में आसान है।

Answer 6

हां।

एक सार्वजनिक varibale पर विचार करें जो अब एक स्ट्रिंग रखता है, आप बस इसे सेट कर सकते हैं। हालांकि, यदि आप निर्णय लेते हैं कि सार्वजनिक चर को एक ऑब्जेक्ट रखना चाहिए जिसे स्ट्रिंग के साथ प्रारंभ किया जाना चाहिए तो आपको अपने मूल ऑब्जेक्ट का उपयोग करके अपना सभी कोड बदलना होगा। लेकिन अगर आप सेटटर का इस्तेमाल करते थे तो आपको केवल स्ट्रिंग को प्रदान की गई स्ट्रिंग के साथ ऑब्जेक्ट को प्रारंभ करने के लिए बदलना होगा।

Answer 7

तुम भी लेखन पहुँच की रक्षा और एक संपत्ति के साथ पढ़ने के लिए उपयोग की अनुमति कर सकते हैं:

public int Version { get; private set; } 

Answer 8

संक्षेप में:

• आप नियंत्रित कर सकते acces (केवल पढ़ने,
  writeonly, पढ़ने/लिखने)
• एक संपत्ति (शून्य आदि के लिए जांचें) को सेट करते समय आप मूल्यों को मान्य कर सकते हैं
• आप कर सकते हैं अतिरिक्त प्रसंस्करण करें, जैसे आलसी प्रारंभिक
• आप अंतर्निहित कार्यान्वयन को बदल सकते हैं। उदाहरण के लिए, एक संपत्ति एक सदस्य के द्वारा समर्थित किया जा सकता है चर अब, लेकिन आप बदल सकते हैं यह एक DB पंक्ति द्वारा किसी भी उपयोगकर्ता कोड को तोड़ने के बिना लिया जाना अभी।