उपयोग ब्लॉक में ऑब्जेक्ट इनिशियलाइज़र

ऑब्जेक्ट्स के शुरुआती (ऑब्जेक्ट इनिशियलाइज़र) C # भाषा की एक उपयोगी विशेषता है, जो आपको इसके निर्माण के दौरान किसी ऑब्जेक्ट के आवश्यक गुणों को आरंभ करने की अनुमति देता है। चूंकि कृत्रिम रूप से यह "फीचर" किसी ऑब्जेक्ट को कंस्ट्रक्टर के माध्यम से गुजरने के साथ शुरू करने के लिए बहुत करीब है, कई डेवलपर्स ओओपी के सिद्धांतों (विशेष रूप से, एक अपरिवर्तनीय की अवधारणा पर) पर हथौड़ा चलाना शुरू करते हैं और जहां भी संभव हो इसका उपयोग करते हैं।

लेकिन भले ही हम होलीवर्स और अस्पष्ट शर्तों पर नहीं जाते हैं, चलो एक छोटा उदाहरण देखते हैं और सोचते हैं कि क्या यह समस्या पैदा कर सकता है या नहीं:

// position     -  long position = -1; using (var file = new FileStream("d:\\1.txt", FileMode.Append) { //   ,     //   ! Position = position }) { //  -   } 

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

.NET में C ++ भाषा के विपरीत, हम अपवाद सुरक्षा के साथ समस्याओं का सामना शायद ही कभी करते हैं, लेकिन यह उन दुर्लभ मामलों में से एक है जब कोड अपवादों के दृष्टिकोण से असुरक्षित होता है ।

इसे समझने के लिए, आइए देखें कि कंपाइलर द्वारा ऑब्जेक्ट इनिशियलाइज़र कैसे लागू किया जाता है:

 class Person { public string Name { get; set; } public int Age { get; set; } } // ... var person = new Person {Name = "John", Age = 42}; 

पहली नज़र में, ऐसा लग सकता है कि ऑब्जेक्ट का इनिशलाइज़र इसके गुणों के बाद के बदलाव के साथ कंस्ट्रक्टर को कॉल करने से ज्यादा कुछ नहीं है। और, वास्तव में, यह जिस तरह से है, केवल एक छोटे से स्पष्टीकरण के साथ:

 var tmp = new Person(); tmp.Name = "Jonh"; tmp.Age = 42; var person = tmp; 

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

 var tmp = new Person(); tmp.Name = "John"; tmp.Age = 42; var person = tmp; 

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

हालाँकि, हालाँकि अस्थायी चर कई समस्याओं को हल करता है, लेकिन यह तब नहीं होता है जब उपयोग करने वाले निर्देश के अंदर ऑब्जेक्ट इनिशलाइज़र का उपयोग किया जाता है । जैसा कि आप जानते हैं, निर्देश का उपयोग निम्नलिखित कोड में किया गया है:

 var file = new FileStream("d:\\1.txt", FileMode.OpenOrCreate); try {} finally { if (file != null) ((IDisposable)file).Dispose(); } 

अब, यदि आप 2 और 2 जोड़ते हैं, तो हमें पता चलता है कि हमारा मूल उदाहरण निम्नलिखित में विस्तृत होता है:

 long position = -1; var tmpFile = new FileStream("d:\\1.txt", FileMode.OpenOrCreate); // !    ,  Dispose   ! tmpFile.Position = position; var file = tmpFile; try { } finally { if (file != null) ((IDisposable)file).Dispose(); } 

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

निष्कर्ष

ऑब्जेक्ट इनिशियलाइज़र एक उपयोगी विशेषता है, लेकिन आपको इसे उपयोग के लिए तैयार करने में भी सक्षम होना चाहिए। यद्यपि वाक्यविन्यास (और शब्दार्थ रूप से, बहुत अधिक) यह सुविधा कंस्ट्रक्टर को कॉल करने के बहुत करीब है, लेकिन, दुर्भाग्य से, वे हमेशा समकक्ष नहीं होते हैं। ओओपी के सिद्धांतों के लिए, यह आप पर निर्भर है कि वस्तुओं के इनिशलाइज़र का उपयोग कब किया जाए और कब नहीं, लेकिन अगर अपवाद और संसाधन प्रबंधन की सुरक्षा की बात आती है, तो आपको निश्चित रूप से यह समझने की ज़रूरत है कि यह सुविधा कैसे काम करती है और इससे क्या होता है।

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