C # प्रकार के साथ सब कुछ ठीक है

" मजबूत प्रकार नियंत्रण: " लेख में पढ़ने के बाद जहां एक ठेठ सी # -प्रोजेक्ट में कमजोर टाइपिंग का एक अवांछित तत्व होता है? "इस दृष्टिकोण की गिरावट से काफी आश्चर्यचकित था, और इस तथ्य से कि किसी ने इस पर ध्यान नहीं दिया।

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

हमारे पास एक GetItem विधि है, जिसे एक निश्चित भंडार से एक वस्तु मिलती है और, लेखक के अनुसार, यह गारंटी देनी चाहिए कि वस्तु शून्य नहीं होगी।

 public Item GetItem(int itemId) { return dataAccessor.getItemById(itemId); } 

यदि आवश्यक वस्तु रिपॉजिटरी में नहीं थी, तो dataAccessor नल को लौटा देगा, जो क्लाइंट को दिया जाएगा और वह, नल के लिए मान की जांच किए बिना, NullReferenceException प्राप्त करेगा। तो कोई कैसे गारंटी दे सकता है कि ऐसा नहीं होगा?

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

एक अन्य विकल्प विधि में एक पोस्ट-कंडीशन जोड़ना है। इस तरह:

 public Item GetItem(int itemId) { Contract.Ensures(Contract.Result<Item>() != null); return dataAccessor.GetItemById(itemId); } 

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

 public Item GetItem(int itemId) { Contract.Requires(dataAccessor.GetItemById(itemId) != null) Contract.Ensures(Contract.Result<Item>() != null); return dataAccessor.GetItemById(itemId); } 

मज़ा है, है ना? रिपॉजिटरी से एक ऑब्जेक्ट प्राप्त करने के लिए, आपको सबसे पहले ऑब्जेक्ट को रिपॉजिटरी से खींचने की आवश्यकता है, क्यों आपको ऑब्जेक्ट को रिपॉजिटरी से खींचने की आवश्यकता है, किस लिए ...

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

दृश्यता के क्षेत्र के बाहर किसी वस्तु के अस्तित्व की गारंटी देने में असमर्थता ऊपर दिए गए लिंक पर लेख में दिए गए दूसरे विचार की ओर ले जाती है। संदर्भ प्रकारों के लिए एक अशक्त कंटेनर का उपयोग करना। I rephrase: nullable reference। तेल तेल है। इस पैटर्न की लोकप्रियता के बारे में सीखना अजीब था।

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

 public Maybe<Item> SomeMethod() { var mbItem = GetMbItem(); if(mbItem.HasValue) { var item = mbItem.Value; ModifyItem(ref item); } return mbItem; } 

यदि RevItem विधि ने ऑब्जेक्ट को बदल दिया है, तो SomeMethod पद्धति पुराने ऑब्जेक्ट के साथ एक कंटेनर लौटाएगी। बाद में जाएं, इस बग को देखें।

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