2011-11-14 12 views
30

मैं FIELDS पर संपत्ति के फायदों को समझता हूं, लेकिन मुझे लगता है कि मैन्युअल कार्यान्वित गुणों पर ऑटो-लागू गुणों का उपयोग करने से वास्तव में कोड को देखने के लिए थोड़ा और संक्षिप्त बनाने के अलावा कोई लाभ नहीं मिलता है।मैन्युअल कार्यान्वित गुणों पर ऑटो-लागू गुणों का उपयोग करने का कोई कारण?

private string _postalCode; 

    public string PostalCode 
    { 
     get { return _postalCode; } 
     set { _postalCode = value; } 
    } 

बजाय::

मैं और अधिक आरामदायक का उपयोग कर लग रहा है

public string PostalCode { get; set; } 

इसका मुख्य कारण है कि अगर मैं कभी मिलता है और सेट के कस्टम कार्यान्वयन के किसी भी प्रकार करना चाहते हैं, मैं बनाने के लिए वैसे भी मेरी निजी संपत्ति एक निजी क्षेत्र द्वारा समर्थित है। तो क्यों शुरुआत से बुलेट को काटते हैं और निरंतरता के लिए सभी गुणों को इस लचीलापन को तुरंत देते हैं? यह वास्तव में एक अतिरिक्त सेकंड नहीं लेता है, यह देखते हुए कि आपको विजुअल स्टूडियो में जो करना है, वह आपके निजी फ़ील्ड नाम पर क्लिक करें, और Ctrl + E दबाएं, और आप कर चुके हैं। और यदि मैं इसे मैन्युअल रूप से करता हूं, तो मैं असंगतता के साथ समाप्त होता हूं जिसमें कुछ विशेष रूप से निजी फ़ील्ड द्वारा समर्थित सार्वजनिक गुणों और कुछ ऑटो-कार्यान्वित गुणों का निर्माण किया जाता है। मैं चारों ओर सुसंगत होने के साथ-साथ सभी ऑटो या सभी मैनुअल के साथ बेहतर महसूस करता हूं।

क्या यह सिर्फ मुझे है? क्या मैं कुछ भूल रहा हूँ? क्या मैं कुछ भूल गया हूँ? क्या मैं स्थिरता पर बहुत अधिक जोर दे रहा हूं? मैं हमेशा सी # सुविधाओं के बारे में वैध चर्चाएं पा सकता हूं, और लगभग हर चीज के लिए हमेशा पेशेवर और विपक्ष होते हैं, लेकिन इस मामले में, मैं वास्तव में ऑटो-कार्यान्वित गुणों का उपयोग करने के खिलाफ अनुशंसा करने वाले किसी भी व्यक्ति को नहीं ढूंढ पाया।

+4

आप कह रहे हैं कि आप अब भी ऐसा कर सकते हैं - क्योंकि भविष्य में आपको शायद 'कुछ ऐसा करने में समय बर्बाद क्यों करें जो त्रुटि के लिए प्रवण है (आप संभवत: प्रतिलिपि बनाना और पेस्ट करना समाप्त कर देंगे), जब आप केवल तभी ऐसा कर सकते हैं जब आवश्यक हो? – Rob

+2

धन्यवाद रॉब। मेरा तर्क यह है कि विजुअल स्टूडियो के साथ, मैं केवल एक अतिरिक्त कुंजी प्रेस के साथ मैन्युअल रूप से कार्यान्वित गुण बना सकता हूं, इसलिए कोई कॉपी/पेस्टिंग नहीं है। और अगर किसी दिन मुझे अपना खुद का कार्यान्वयन करने की ज़रूरत है, तो मैं ऑटो-कार्यान्वित गुणों और मैन्युअल रूप से कार्यान्वित गुणों के बीच एक गड़बड़ी के साथ समाप्त नहीं होता, यह 100% एक या 100% दूसरा है। शुरुआत से मैन्युअल पर पूरी तरह से जाकर, मैं किसी भी समय अपने गुणों को स्वत: कार्यान्वित किए बिना अपना स्वयं का कार्यान्वयन कर सकता हूं, और कुछ गुण मैन्युअल हो सकते हैं। हालांकि, मैं निश्चित रूप से आपका बिंदु देखता हूं। – CptSupermrkt

+2

उस स्थिति में, मैं 100% मैन्युअल कार्यान्वयन के साथ चिपकने में आपके साथ हूं .. वीएस 2010 (कम से कम) में मैन्युअल गेटर्स/सेटर्स – Rob

उत्तर

34

यह आपको संक्षिप्त होने से परे कुछ अतिरिक्त प्रदान नहीं करता है। यदि आप अधिक वर्बोज़ सिंटैक्स पसंद करते हैं, तो हर तरह से इसका उपयोग करें।

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

ऑटो प्रोप के बारे में आपका बिंदु बहुत लचीला नहीं है, यह एक अच्छा है। आपके पास केवल एक ही लचीलापन है जो दायरे को सीमित करने के लिए private get या private set का उपयोग कर रहा है। यदि आपके गेटर्स या सेटर्स के पास कोई जटिलता है तो ऑटो प्रोप अब एक व्यवहार्य विकल्प नहीं हैं।

+0

बहुत बहुत धन्यवाद, यह बहुत अधिक इसे साफ़ करता है। – CptSupermrkt

+0

मेरे अनुभव में सार्वजनिक गुण ओओपी की मानसिकता से लोगों को तोड़ देते हैं। मेरे पास एक प्रोजेक्ट में अब ऑब्जेक्ट्स हैं जिनमें कुछ प्रॉपर्टी केवल कुछ समय शुरू हुई हैं, इसलिए यह अनुमान लगाया जाता है कि क्या यह संपत्ति शून्य है या नहीं और कोडबेस में बहुत से क्षेत्र हैं जो नल की जांच करते हैं। मुझे लगता है कि वे कुछ मामलों के लिए महान हैं, अगर मैंने हाइलाइट किया तो वे शैतान प्रतीत होते हैं। – CodyEngel

+0

@ कोडीइंजेल इस बात की कोई गारंटी नहीं है कि किसी एक्सेसर के माध्यम से ऑब्जेक्ट का उपयोग किया जा रहा है या तो शून्य नहीं है। अगर लोग गुणों के साथ मैला कोड लिखेंगे, तो वे बिना मैला कोड लिखेंगे। – iheanyi

2

ऐसे लोग हैं जो think that automatic properties can be somewhat evil हैं लेकिन इसके अलावा वे सिंटैक्टिक चीनी हैं। आपको कोड की कुछ पंक्तियों को सहेजने के अलावा उन्हें उपयोग करके कुछ भी हासिल नहीं होता है और आप संभावित रूप से अपने लिए अधिक काम कर सकते हैं (इसे बाद में मैन्युअल रूप से कार्यान्वित करके, क्योंकि आप कुछ जांच करना चाहते हैं या किसी ईवेंट को उठाना चाहते हैं)। प्रोग्रामिंग (इम्हो) में संगठनात्मकता काफी मूल्यवान है।

+0

आह, तो इस पर कहीं कहीं चर्चा हुई :) लिंक के लिए धन्यवाद! – CptSupermrkt

2

मैं अन्य सभी के बारे में पता नहीं है, लेकिन मैं एक पल को थामने के लिए सोचने के लिए मैं अपने चर और कार्यों ताकि अन्य लोग मेरी कोड को समझ सकता हूँ क्या नाम रखना चाहिए होते हैं।

तो जब मैं ऑटो -implemented गुण, का उपयोग मैं केवल एक बार को रोकने के लिए किया है।

जब मैं एक समर्थन क्षेत्र जरूरत है मैं दो बार को थामने के लिए है, तो यह विकास एक सा :)

तरह से मैं यह कर रहा है धीमा कर देती है:

  1. यह एक निजी चर बनाओ शुरुआत में
  2. यदि आवश्यक हो तो इसे सार्वजनिक ऑटो-लागू करें।
  3. मुझे बैकिंग फ़ील्ड में बदलें यदि मुझे कुछ कोड प्राप्त करने या सेट करने की आवश्यकता है।

कक्षा के विभिन्न गुण अलग-अलग दिखाई देने पर कुछ भी गलत नहीं है।

2

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

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

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

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

9

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

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

मैन्युअल रूप से लागू गुण का उपयोग करके आप गारंटी रहे हैं कि समर्थन क्षेत्र कभी नहीं बदलता (जब तक आप यह विशेष रूप से बदलें)।

कि मिनट अंतर के अलावा, एक स्वत: संपत्ति एक सामान्य संपत्ति है कि एक समर्थन क्षेत्र के साथ स्वचालित रूप से कार्यान्वित किया जाता है है।

0

लाभ मैं ऑटो गुण उपयोग कर रहा है देखने में से एक; एप्लिकेशन को डिबग करने के दौरान यह अनावश्यक गेट/सेट सेक्शन में कदम नहीं उठाएगा। मुझे पता है कि हम डीबगर गुणों या चरण के ऊपर से बच सकते हैं; हालांकि बड़े आवेदन पर डीबग होने पर यह सबसे अधिक मामला होता है।

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