कोड अनुबंध में वैकल्पिक पूर्व शर्त जाँच

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

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

हालाँकि, कोड कॉन्ट्रैक्ट एक अतिरिक्त "कम्पैटिबिलिटी मोड" का समर्थन करता है, जो आपको परिणामी कोड में "हार्डवायर" पूर्व शर्त की जांच करने की अनुमति देता है, ताकि वे सबको दिखाई दें, चाहे कॉन्ट्रैक्ट डेवलपर की मशीन पर स्थापित हो या नहीं।

समस्या कथन

आइए एक उदाहरण को देखकर शुरू करें जो अधिक स्पष्ट रूप से दिखाता है कि समस्या क्या है।

class SimpleClass { public int Foo(string s) { Contract.Requires(s != null); return s.Length; } } 

इस कोड के साथ सब कुछ ठीक है, और जब हम फू विधि को शून्य के साथ कॉल करने का प्रयास करते हैं, तो हमें एक अनुबंध उल्लंघन होता है कि, जब कोड कॉन्ट्रैक्ट्स लाइब्रेरी स्थापित हो जाती है और प्रीऑन्डिशन चेकिंग चालू हो जाती है, तो यह एक अपवाद 'System.Diagnonics.Contracts .__ ContractsRuntime.ContractException' को फेंक देगा।

हां, यह बिल्कुल वही है जो हम उम्मीद कर रहे हैं, लेकिन ख़ासियत यह है कि अपवाद पीढ़ी कोड संकलक द्वारा नहीं, बल्कि संकलन के तुरंत बाद शुरू होने वाली एक अलग प्रक्रिया से उत्पन्न होता है । और इसका मतलब है कि कोड कॉन्ट्रैक्ट्स लाइब्रेरी के बिना, इस कोड का निष्पादन NullReferenceExcpetion की पीढ़ी को जन्म देगा, क्योंकि तर्कों का कोई अतिरिक्त सत्यापन नहीं रहेगा। मैं बार-बार इस तथ्य पर आया हूं कि यह व्यवहार निम्नलिखित प्रतिक्रिया के बारे में है: "डब्ल्यूटीएफ? मेरा चेक कहां गया! ”

चूंकि हम ऐसे "डब्ल्यूटीएफ?" को सुनना नहीं चाहते हैं, इसलिए हमारे सहयोगियों के पास जिनके पास कोई अनुबंध नहीं है, हम एक पूर्व-भुगतान जांच को अधिक गहन तरीके से सीवे करने का एक तरीका चाहेंगे।

मैनुअल पूर्व शर्त जाँच

कोड अनुबंध पुस्तकालय आपको पुराने प्रारूप में पूर्व शर्त का उपयोग करने की अनुमति देता है। इसका मतलब यह है कि यदि मौजूदा पद्धति में पहले से ही इनपुट मापदंडों (यानी, पूर्व शर्त की जांच) की जांच शामिल है, तो उन्हें पूर्ण-पूर्व वरीयता में परिवर्तित करने के लिए, उनके बाद अनुबंध कॉल को जोड़ने के लिए पर्याप्त है । EndContractBlock :

 public class SimpleClass { public int Foo(string s) { if (s == null) throw new ArgumentNullException("s"); Contract.EndContractBlock(); return s.Length; } } 

कॉन्ट्रैक्ट कॉल जोड़ना । EndContractBlock पूर्ण मापदंडों में इनपुट मापदंडों के एक (या कई) चेक को बदल देता है। अब, ऐसे किसी भी डेवलपर के लिए, जिसका कोई अनुबंध नहीं है, यह कोड पहले की तरह दिखेगा। उसी समय, अनुबंध के मालिकों के रूप में, वे अपने सभी लाभों का लाभ उठाने में सक्षम होंगे, जैसे कि स्टैटिक चेकर का उपयोग करके कार्यक्रम की वैधता की जाँच करना, प्रलेखन के स्वत: उत्पादन, अनुबंधों के सभी उल्लंघनों को पकड़ने की संभावना (नीचे इस पर अधिक)। सत्यापन की इस पद्धति के बीच अंतर केवल इतना है कि उन्हें बंद नहीं किया जा सकता है और कोड को पूरी तरह से काट दिया जाता है।

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

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

मौजूदा सत्यापन विधियों का उपयोग करना

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

नोट
दुर्भाग्य से, विशेषता ContractArgumentValidatorAttribute .NET फ्रेमवर्क संस्करण 4.0 का हिस्सा नहीं है, यह केवल संस्करण 4.5 में दिखाई देगा। इस स्थिति को अपने प्रोजेक्ट में ContractExtensions.cs फ़ाइल जोड़कर हल किया जाता है, जो कोड अनुबंध लाइब्रेरी स्थापित करने के बाद% ProgramFiles% \ Microsoft \ Contracts \ Language \ CSharp में दिखाई देगा।

 public static class Guard { [ContractArgumentValidatorAttribute] public static void IsNotNull<T>(T t) where T : class { if (t == null) throw new ArgumentNullException("t"); Contract.EndContractBlock(); } } 

अब हम पूर्व- स्थितियों की जांच करने के लिए अच्छे पुराने IsNotNull विधि का उपयोग कर सकते हैं:

 public int Foo(string s) { Guard.IsNotNull(s); return s.Length; } 

विषय से विचलन। Contract.ContractFailed

आपने देखा होगा कि अनुबंध विधि के दो संस्करण हैं । आवश्यकता है , जिनमें से एक सामान्य है और इसका उपयोग वांछित प्रकार के अपवाद को उत्पन्न करने के लिए किया जा सकता है, गैर-सामान्यीकृत संस्करण के उल्लंघन से अनुबंध अपवाद का आंतरिक अपवाद उत्पन्न होता है।

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

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

निष्कर्ष

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