2010-08-19 11 views
10

मैं सामान्य अभ्यास की बेहतर समझ प्राप्त करने की कोशिश कर रहा हूं ... विशेष रूप से इसे() को एक कन्स्ट्रक्टर में प्राप्त करना। मैं समझता हूं कि इसका कम कोड है, लेकिन मैं इसे कम पठनीय मानता हूं। क्या यह इस तरह से करने के लिए आम/अच्छा अभ्यास है? या क्या यह दूसरा कन्स्ट्रक्टर लिखना बेहतर है जो इसे विशेष रूप से संभालता है?: यह() एक निर्माता के रूप में

public SomeOtherStuff(string rabble) : this(rabble, "bloop") { } 

या

Public SomeOtherStuff(string rabble) 
{ 
    //set bloop 
} 

किसी भी इनपुट होगा बहुत

+3

'यह()' एक संरचना प्रकार पर ऑटो-गुण रखने का एक अच्छा तरीका है और फिर भी उन्हें एक पैरामीट्रिज्ड कन्स्ट्रक्टर में सेट करने की अनुमति देता है। 'इस()' के बिना, आपको स्पष्ट बैकिंग फ़ील्ड का उपयोग करने की आवश्यकता है। –

+0

@ डैन: यह शानदार है, मैंने कभी सोचा नहीं!भविष्य में मैं उन गुणों में 'this()' का उपयोग करूंगा जिनमें ऑटो-गुण हैं! धन्यवाद! – Timwi

उत्तर

17

जब भी संभव हो this() का उपयोग करना अच्छा अभ्यास है। अन्यथा आप कुछ कोड डुप्लिकेट करेंगे, जो DRY का उल्लंघन करता है (स्वयं को दोहराएं) सिद्धांत। खुद को दोहराने में समस्या यह है कि हर बार आपको एक बदलाव करने की आवश्यकता होती है - भले ही यह कोड की एक पंक्ति में एक साधारण परिवर्तन हो - आपको को समान एकाधिक स्थानों में बदलने के लिए याद रखें, और एकाधिक रखें कॉपी सिंक्रनाइज़।

आपको कोड को केवल "डुप्लिकेट" करना चाहिए जब आपको इसकी आवश्यकता हो क्योंकि इसे अलग होना चाहिए, इसलिए यह अब डुप्लिकेट नहीं है। इस तरह, डुप्लिकेट होने पर पाठक को एक संदेश होता है कि कोड वास्तव में अलग है, और ऐसा कारण है।

+0

महान उत्तर और यह निश्चित रूप से मेरे प्रश्न को स्पष्ट करता है। मैंने डीआरवाई सिद्धांत नहीं देखा था और मुझे विश्वास है कि बोर्ड में मेरा कोड सुधार जाएगा। धन्यवाद! – Aardvark

0

मैं विश्वसनीयता के लिए पठनीयता और अधिक के बारे में कम परवाह की सराहना की।

चेनिंग कन्स्ट्रक्टर कन्स्ट्रक्टर विधि निकायों की प्रतिलिपि बनाने से कहीं बेहतर है।

+4

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

+1

@foo छोटी गाड़ी और पठनीय या अस्पष्ट लेकिन भरोसेमंद? बेशक, यह हमेशा एक या/या स्थिति नहीं है, लेकिन यदि आपके पास एक या दूसरे को करने का विकल्प है, तो दूसरा बेहतर। साथ ही, सबसे अपठनीय कोड कोड टिप्पणियों के आवेदन के साथ समझने से अधिक हो जाता है! – Will

+0

उह, आप "पठनीय" के साथ "बग्गी" को क्यों जोड़ते हैं? "पठनीय और भरोसेमंद" के बारे में कैसे? वे पारस्परिक रूप से विशिष्ट नहीं हैं। –

1

इस प्रकार आप चेन कंस्ट्रक्टर कैसे हैं और यह करने के लिए एक पूरी तरह से मान्य बात है।

7

दो अलग कन्स्ट्रक्टरों के साथ समस्या यह है कि वे अक्सर समान कोड रखते हैं, जो बाद में रिफैक्टरिंग के साथ समस्याएं पैदा कर सकता है, जब एक कन्स्ट्रक्टर बदल जाता है और दूसरा नहीं। तो आप DRY principle के आवेदन के रूप में इस() के साथ कन्स्ट्रक्टर चेनिंग देख सकते हैं।

2

प्रारंभिक सूची उद्योग में बहुत आम प्रथा है।

पठनीयता के लिए ... यह राय का विषय है। लेकिन रखरखाव आमतौर पर प्रयास करने के लिए एक उच्च लक्ष्य है।

DRY एक अच्छी बात है :)

1

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

इसके अलावा, मैं हमेशा जिस कोड पर काम कर रहा हूं उसकी शैली में कोड करने का प्रयास करता हूं - इसलिए यदि मुख्य शैली एक या दूसरी है, तो मैं उस शैली के साथ स्थिरता के लिए जाऊंगा।

0

डीआरवाई के लिए एक और तरीका प्रारंभिक विधि लिख रहा है, उदाहरण के लिए Init(rabble, bloop) और सभी रचनाकार इस विधि को कॉल करते हैं।

यह कम भ्रमित और अधिक लचीला होता है, खासकर जहां कई रचनाकार हैं।

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