हम टाइप कंट्रोल को मजबूत करते हैं: जहां एक विशिष्ट सी # -प्रोजेक्ट में कमजोर टाइपिंग का एक अवांछित तत्व होता है?

समस्या

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

सक्रिय विकास के वर्ष के लिए मेरी वर्तमान परियोजना में कोई NullReferenceException नहीं थी। मैं यथोचित विश्वास कर सकता हूं कि यह नीचे वर्णित तकनीकों के आवेदन का एक परिणाम है।

कोड के एक टुकड़े पर विचार करें:

public interface IUserRepo { User Get(int id); User Find(int id); } 

इस इंटरफ़ेस के लिए अतिरिक्त टिप्पणी की आवश्यकता होती है: “हमेशा रिटर्न शून्य नहीं मिलता है, लेकिन यदि वस्तु नहीं मिली है तो एक अपवाद फेंकता है; और ढूंढें, नहीं मिल रहा है, अशक्त है। इन विधियों के लेखक द्वारा निहित "वांछित" रिटर्न प्रकार अलग हैं: "आवश्यक उपयोगकर्ता" और "शायद उपयोगकर्ता"। और "घोषित" प्रकार एक और एक ही है। यदि भाषा हमें इस अंतर को स्पष्ट रूप से व्यक्त करने के लिए मजबूर नहीं करती है, तो इसका मतलब यह नहीं है कि हम अपनी पहल पर ऐसा नहीं कर सकते हैं और नहीं करना चाहिए।

निर्णय

कार्यात्मक भाषाओं में, उदाहरण के लिए, F # में, एक मानक प्रकार है FSharpOption <T>, जो किसी भी प्रकार के लिए एक कंटेनर का प्रतिनिधित्व करता है, जिसमें या तो टी का एक मान हो सकता है या अनुपस्थित हो सकता है। आइए विचार करें कि हम इस प्रकार से क्या संभावनाएं रखना चाहेंगे ताकि यह उपयोग करने के लिए सुविधाजनक हो, जिसमें कार्यात्मक भाषाओं के साथ विभिन्न डिग्री शैलियों के अनुयायियों को अलग-अलग परिचितों की डिग्री शामिल हो।
इस काल्पनिक प्रकार को देखते हुए, हम निम्नलिखित रूप में अपनी रिपॉजिटरी को फिर से लिख सकते हैं:

 public interface IUserRepo { User Get(int id); Maybe<User> Find(int id); } 

तुरंत एक आरक्षण करें कि पहली विधि अभी भी अशक्त हो सकती है। भाषा के स्तर पर इस पर प्रतिबंध लगाने का कोई आसान तरीका नहीं है। हालांकि, यह कम से कम विकास टीम में समझौते के स्तर पर किया जा सकता है। इस तरह के उपक्रम की सफलता लोगों पर निर्भर करती है; मेरी परियोजना में, इस तरह के एक समझौते को स्वीकार किया गया है और सफलतापूर्वक मनाया जा रहा है।
बेशक, आप आगे जा सकते हैं और स्रोत कोड में शून्य कीवर्ड की उपस्थिति के लिए विधानसभा प्रक्रिया की जाँच कर सकते हैं (इस नियम के निर्दिष्ट अपवादों के साथ)। लेकिन अभी तक इसकी कोई जरूरत नहीं थी, बस आंतरिक अनुशासन ही काफी है।
सामान्य तौर पर, आप आगे भी जा सकते हैं, उदाहरण के लिए, अनुबंध को मजबूर करना। अनुबंध (अनुबंध। रेज़ल्ट <टी> ()! = नल) को कुछ एओपी समाधान के माध्यम से सभी उपयुक्त तरीकों में, उदाहरण के लिए, पोस्टशार्प, जिसमें किसी भी मामले में सदस्य भी शामिल हैं; कम अनुशासन के साथ अस्वास्थ्यकर अशक्त वापसी नहीं कर पाएंगे।

इंटरफ़ेस का नया संस्करण स्पष्ट रूप से घोषित करता है कि फाइंड को ऑब्जेक्ट नहीं मिल सकता है, जिस स्थिति में यह शायद वापस लौटेगा <User> .Nothing। इस मामले में, कोई भी शून्य के लिए परिणाम की जांच करने के लिए भूल नहीं सकता है। हम आगे इस तरह के भंडार के उपयोग के बारे में सोचते हैं:

 //      null var user = repo.Find(userId); //    User,  Maybe<User> var userName = user.Name; //  ,  Maybe  Name var maybeUser = repo.Find(userId); //    , string userName; if (maybeUser.HasValue) //           { var user = maybeUser.Value; userName = user.Name; } else userName = "unknown"; 

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

 string userName = repo.Find(userId).Select(u => u.Name).OrElse("unknown"); 

उन लोगों के लिए जो कार्यात्मक भाषाओं के करीब हैं और क्या करते हैं, पूरी तरह से "कार्यात्मक" शैली का समर्थन किया जा सकता है:

 string userName = (from user in repo.Find(userId) select user.Name).OrElse("unknown"); 

या, एक उदाहरण अधिक जटिल है:

 ( from roleAProfile in provider.FindProfile(userId, type: "A") from roleBProfile in provider.FindProfile(userId, type: "B") from roleCProfile in provider.FindProfile(userId, type: "C") where roleAProfile.IsActive() && roleCProfile.IsPremium() let user = repo.GetUser(userId) select user ).Do(HonorAsActiveUser); 

इसके समतुल्य समकक्ष के साथ:

 var maybeProfileA = provider.FindProfile(userId, type: "A"); if (maybeProfileA.HasValue) { var profileA = maybeProfileA.Value; var maybeProfileB = provider.FindProfile(userId, type: "B"); if (maybeProfileB.HasValue) { var profileB = maybeProfileB.Value; var maybeProfileC = provider.FindProfile(userId, type: "C"); if (maybeProfileC.HasValue) { var profileC = maybeProfileC.Value; if (profileA.IsActive() && profileC.IsPremium()) { var user = repo.GetUser(userId); HonorAsActiveUser(user); } } } } 

इसके अपने निकट संबंधी के साथ शायद <T> के एकीकरण की भी आवश्यकता है - IEnumerable <T>, कम से कम इस रूप में:

 var admin = users.MaybeFirst(u => u.IsAdmin); //  FirstOrDefault(u => u.IsAdmin); Console.WriteLine("Admin is {0}", admin.Select(a => a.Name).OrElse("not found")); 

उपरोक्त "सपनों" से यह स्पष्ट है कि आप शायद प्रकार में क्या चाहते हैं

• मूल्य उपस्थिति की जानकारी तक पहुंच
• और यदि उपलब्ध हो तो स्वयं मूल्य के लिए
• स्ट्रीमिंग कॉल शैली के लिए सुविधाजनक तरीकों (या विस्तार विधियों) का एक सेट
• LINQ अभिव्यक्ति वाक्यविन्यास समर्थन
• IEnumerable <T> और अन्य घटकों के साथ एकीकरण, जब काम करते हैं जिसके साथ अक्सर मूल्य की कमी की स्थितियां होती हैं

आइए विचार करें कि नुगेट हमें परियोजना में त्वरित समावेश के लिए क्या समाधान दे सकता है और उपरोक्त मानदंडों के अनुसार उनकी तुलना कर सकता है:

Nuget पैकेज नाम और प्रकार प्रकार	HasValue	मूल्य	FluentAPI	LINQ समर्थन	IEnumerable के साथ एकीकरण	नोट्स और स्रोत कोड
विकल्प, वर्ग	वहाँ है	नहीं, केवल पैटर्न-मिलान	न्यूनतम	नहीं	नहीं	github.com/tejacques/Option
Strilanc.Value.May, संरचना	वहाँ है	नहीं, केवल पैटर्न-मिलान	धनी	वहाँ है	वहाँ है	मई में एक वैध मूल्य के रूप में शून्य को स्वीकार करता है github.com/Strilanc/May
विकल्प, संरचना	वहाँ है	वहाँ है	औसत	वहाँ है	वहाँ है	या तो प्रकार भी उपलब्ध है। github.com/davidsidlinger/options
नेवरनल क्लास	वहाँ है	वहाँ है	औसत	नहीं	नहीं	github.com/Bomret/NeverNull
कार्यात्मक	वहाँ है	वहाँ है	धनी	वहाँ है	वहाँ है	github.com/AndreyTsvetkov/Functional.Maybe
शायद कोई प्रकार नहीं	-	-	न्यूनतम	नहीं	-	विस्तार के तरीके सादे नल के साथ काम करते हैं github.com/hazzik/Maybe अद्यतन: यहाँ एक समान दृष्टिकोण और विस्तृत विवरण के साथ mezastel से एक स्क्रीनकास्ट है: www.techdays.ru/videos/44.html
WeeGems.Options, संरचना	वहाँ है	वहाँ है	न्यूनतम	नहीं	नहीं	अन्य कार्यात्मक उपयोगिताओं भी हैं: ज्ञापन, कार्यों का आंशिक उपयोग bitbucket.org/MattDavey/weegems

ऐसा हुआ कि मेरी परियोजना ने अपना पैकेज बढ़ा दिया है, यह उपरोक्त में से एक है।

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

सबसे अमीर पैकेज Strilanc.Value.Maybe हैं ( यहां लेखक बताते हैं, विशेष रूप से, उन्होंने फैसला किया कि क्यों (नल) .ToMaybe () शायद एक ही नहीं है। नथिंग), Functional.Maybe, विकल्प।

स्वाद के लिए चुनें। सामान्य तौर पर, मैं, निश्चित रूप से, Microsoft से एक मानक समाधान , साथ ही C #, टुपल्स आदि में कार्यात्मक प्रकार :) चाहता हूं। रुको और देखो।

UPD: कॉमरेड aikixd ने एक विरोधी लेख लिखा।