सी # 8 में इंटरफेस: डिफ़ॉल्ट कार्यान्वयन में खतरनाक अनुमान

नमस्कार, हेब्र!

C # 8 के विषय की खोज के हिस्से के रूप में, हम आपको इंटरफेस लागू करने के लिए नए नियमों पर निम्नलिखित लेख पर चर्चा करने का सुझाव देते हैं।



C # 8 में इंटरफेस को कैसे संरचित किया जाता है , इस पर ध्यान से देखते हुए, आपको यह विचार करने की आवश्यकता है कि इंटरफेस को लागू करते समय, आप डिफ़ॉल्ट रूप से फायरवुड को तोड़ सकते हैं।

डिफ़ॉल्ट कार्यान्वयन से संबंधित मान्यताओं से दूषित कोड, रनटाइम अपवाद और खराब प्रदर्शन हो सकता है।

C # 8 इंटरफेस की सक्रिय रूप से विज्ञापित सुविधाओं में से एक यह है कि आप मौजूदा कार्यान्वयनकर्ताओं को तोड़ने के बिना सदस्यों को इंटरफ़ेस में जोड़ सकते हैं। लेकिन इस मामले में असावधानी बड़ी समस्याओं से भरा है। उस कोड पर विचार करें जिसमें गलत धारणाएं बनाई गई हैं - इससे यह स्पष्ट हो जाएगा कि ऐसी समस्याओं से बचना कितना महत्वपूर्ण है।

इस लेख के लिए सभी कोड GitHub पर पोस्ट किए गए हैं: jeremybytes / interfaces-in-csharp-8 , विशेष रूप से डेंजरसएसम्यूशंस प्रोजेक्ट में ।

नोट: यह आलेख वर्तमान में केवल .NET कोर 3.0 में लागू C # 8 की सुविधाओं पर चर्चा करता है। मेरे द्वारा उपयोग किए गए उदाहरणों में, दृश्य स्टूडियो 16.3.0 और .NET कोर 3.0.100 ।

कार्यान्वयन विवरण के बारे में अनुमान

इस समस्या का मुख्य कारण मैं इस प्रकार व्यक्त करता हूं: मुझे इंटरनेट पर एक लेख मिला जहां लेखक कार्यान्वयन के बारे में बहुत खराब धारणाओं के साथ कोड प्रस्तुत करता है (मैं लेख को इंगित नहीं करूंगा क्योंकि मैं नहीं चाहता कि लेखक टिप्पणियों के साथ लुढ़का हो; मैं उनसे व्यक्तिगत रूप से संपर्क करूंगा) ।

लेख इस बारे में बात करता है कि डिफ़ॉल्ट कार्यान्वयन कितना अच्छा है, क्योंकि यह हमें कोड के लागू होने के बाद भी इंटरफेस को पूरक करने की अनुमति देता है। हालाँकि, इस कोड में कई गलत धारणाएँ बनाई गई हैं (कोड मेरे गीताप्रेस में फ़ोल्डर के BadInterface में है)

यहाँ मूल इंटरफ़ेस है:



बाकी लेख MyFile इंटरफ़ेस (मेरे लिए, MyFile.cs फ़ाइल में) के कार्यान्वयन को प्रदर्शित करता है:

लेख तब दिखाता है कि आप डिफ़ॉल्ट कार्यान्वयन के साथ Rename कैसे जोड़ सकते हैं, और यह मौजूदा MyFile वर्ग को नहीं तोड़ देगा।

यहाँ अद्यतन इंटरफ़ेस है ( IFileHandler.cs फ़ाइल से):



MyFile अभी भी काम करता है, इसलिए सब कुछ ठीक है। तो? वास्तव में नहीं।

बुरी धारणाएँ

नाम बदलने की विधि के साथ मुख्य समस्या यह है कि एक बड़ी धारणा इसके साथ जुड़ी हुई है: कार्यान्वयन फाइल सिस्टम में स्थित एक भौतिक फ़ाइल का उपयोग करते हैं।

उस कार्यान्वयन पर विचार करें जो मैंने रैम में स्थित फ़ाइल सिस्टम में उपयोग के लिए बनाया था। (नोट: यह मेरा कोड है। यह उस लेख से नहीं है जिसकी मैं आलोचना करता हूं। आपको फ़ाइल का पूरा कार्यान्वयन MemoryStringFileHandler.cs में मिलेगा।)



यह वर्ग एक औपचारिक फ़ाइल प्रणाली को लागू करता है जो रैम में स्थित एक शब्दकोश का उपयोग करता है, जिसमें पाठ फाइलें होती हैं। यहाँ कुछ भी नहीं है जो भौतिक फ़ाइल सिस्टम को प्रभावित करेगा; आमतौर पर System.IO कोई संदर्भ नहीं है।

दोषपूर्ण कार्यान्वयन करनेवाला

इंटरफ़ेस को अपडेट करने के बाद, यह वर्ग क्षतिग्रस्त है।

यदि क्लाइंट कोड का नाम बदलें विधि है, तो यह रनटाइम त्रुटि उत्पन्न करेगा (या, इससे भी बदतर, फ़ाइल सिस्टम में संग्रहीत फ़ाइल का नाम बदलें)।

यहां तक ​​कि अगर हमारा कार्यान्वयन भौतिक फ़ाइलों के साथ काम करेगा, तो यह क्लाउड स्टोरेज में स्थित फाइलों तक पहुंच सकता है, और ऐसी फाइलें सिस्टम के माध्यम से सुलभ नहीं हैं।

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

चूंकि गलत धारणा इंटरफ़ेस की चिंता करती है, इसलिए इस इंटरफ़ेस के कार्यान्वयनकर्ता दूषित हैं।

अनुचित भय?

इस तरह के डर को निराधार मानना ​​बेकार है। जब मैं कोड में गालियों के बारे में बात करता हूं, तो वे मुझे जवाब देते हैं: "ठीक है, यह सिर्फ इतना है कि एक व्यक्ति को पता नहीं है कि कैसे प्रोग्राम करना है।" मैं इससे असहमत नहीं हो सकता।

आमतौर पर मैं ऐसा करता हूं: मैं इंतजार करता हूं और देखता हूं कि यह कैसे काम करेगा। उदाहरण के लिए, मुझे डर था कि "स्थिर उपयोग" की संभावना का दुरुपयोग किया जाएगा। अब तक, यह आश्वस्त नहीं हुआ है।

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


प्रदर्शन के मुद्दे

मैंने यह सोचना शुरू कर दिया कि यदि हम इंटरफ़ेस कार्यान्वयनकर्ताओं के बारे में गलत धारणाएं बनाते हैं तो अन्य समस्याएं क्या हो सकती हैं।

पिछले उदाहरण में, कोड को कहा जाता है जो इंटरफ़ेस के बाहर है (इस मामले में, System.IO के बाहर)। आप शायद इस बात से सहमत होंगे कि इस तरह की कार्रवाई एक खतरनाक घंटी है। लेकिन, अगर हम उन चीजों का उपयोग करते हैं जो पहले से ही इंटरफ़ेस का हिस्सा हैं, तो सब कुछ ठीक होना चाहिए?

हमेशा नहीं।

एक व्यक्त उदाहरण के रूप में, मैंने आइडियाडर इंटरफ़ेस बनाया।

स्रोत इंटरफ़ेस और इसका कार्यान्वयन

यहां मूल IReader इंटरफ़ेस है ( IReader.cs फ़ाइल से - हालांकि अब इस फ़ाइल में पहले से ही अपडेट हैं):



यह एक सामान्य विधि इंटरफ़ेस है जो आपको केवल-पढ़ने के लिए आइटम का संग्रह प्राप्त करने की अनुमति देता है।

इस इंटरफ़ेस के कार्यान्वयन में से एक फाइबोनैचि संख्याओं का एक क्रम उत्पन्न करता है (हाँ, मुझे फिबोनाची अनुक्रम बनाने में एक अस्वास्थ्यकर हित है)। यहाँ FibonacciReader इंटरफ़ेस है ( FibnoteReader.cs फ़ाइल से - यह मेरे गिट्टू पर भी अद्यतन किया गया है):



FibonacciSequence क्लास IEnumerable <int> (फाइबोनैचिस्सेंस से.इन फ़ाइल से) का कार्यान्वयन है। यह डेटा प्रकार के रूप में 32-बिट पूर्णांक का उपयोग करता है, इसलिए अतिप्रवाह काफी जल्दी होता है।



यदि आप इस कार्यान्वयन में रुचि रखते हैं, तो मेरे TDDing को C # लेख में एक फाइबोनैचि अनुक्रम में देखें।

DangerousAssumations परियोजना एक सांत्वना अनुप्रयोग है जो फाइबोनैचिआर के परिणामों को प्रदर्शित करता है ( Program.cs फ़ाइल से):



और यहाँ निष्कर्ष है:



अद्यतित इंटरफ़ेस

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

यहां हमारा इंटरफ़ेस है जिसमें GetItemAt पद्धति GetItemAt ( IReader.cs फ़ाइल के अंतिम संस्करण से):



यहाँ GetItemAt एक डिफ़ॉल्ट कार्यान्वयन मानता है। पहली नज़र में - इतना बुरा नहीं है। यह एक मौजूदा इंटरफ़ेस सदस्य ( GetItems ) का उपयोग करता है, इसलिए, यहां कोई "बाहरी" धारणा नहीं बनाई गई है। परिणामों के साथ, वह LINQ विधि का उपयोग करता है। मैं LINQ का बहुत बड़ा प्रशंसक हूँ, और यह कोड, मेरी राय में, यथोचित रूप से निर्मित है।

प्रदर्शन के अंतर

चूंकि डिफ़ॉल्ट कार्यान्वयन GetItems कॉल GetItems , इसलिए किसी विशिष्ट आइटम को चुनने से पहले पूरे संग्रह को वापस करना होगा।

FibonacciReader के मामले में FibonacciReader इसका अर्थ है कि सभी मान उत्पन्न होंगे। एक अद्यतन रूप में, Program.cs फ़ाइल में निम्न कोड होगा:



तो हम GetItemAt कहते हैं। यहाँ निष्कर्ष है:



यदि हम फाइबोनैचिसेन्सेंस.केंस फ़ाइल के अंदर एक चेकपॉइंट लगाते हैं, तो हम देखेंगे कि इसके लिए संपूर्ण अनुक्रम उत्पन्न होता है।

कार्यक्रम शुरू करने के बाद, हम इस नियंत्रण बिंदु पर दो बार ठोकर खाएंगे: पहला जब GetItems पर कॉल किया GetItems , और तब GetItemAt पर कॉल किया GetItemAt ।

प्रदर्शन के लिए हानिकारक मानते हैं

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

हमारे FibonacciReader साथ काम करते हुए, हम प्रत्येक नए तत्व की गणना करते हैं। इस प्रकार, पूरी सूची को केवल एक तत्व प्राप्त करने के लिए पूरी तरह से गणना की जानी चाहिए जिसकी हमें आवश्यकता है। फाइबोनैचि अनुक्रम गणना एक ऐसा ऑपरेशन है जो प्रोसेसर को बहुत अधिक लोड नहीं करता है, लेकिन क्या होगा यदि हम कुछ अधिक जटिल से निपटते हैं, उदाहरण के लिए, हम अभाज्य संख्याओं की गणना करेंगे?

आप कह सकते हैं: “ठीक है, हमारे पास एक GetItems तरीका है जो सब कुछ लौटाता है। यदि यह बहुत लंबे समय तक काम करता है, तो शायद यह यहां नहीं होना चाहिए। और यह एक ईमानदार बयान है।

हालाँकि, कॉलिंग कोड को इस बारे में कुछ नहीं पता है। यदि मैं GetItems कॉल करता GetItems , तो मुझे पता है कि (शायद) मेरी जानकारी को नेटवर्क से गुजरना होगा, और यह प्रक्रिया तारीख-गहन होगी। यदि मैं किसी एक वस्तु की माँग करता हूँ, तो मुझे ऐसी लागतों की अपेक्षा क्यों करनी चाहिए?

विशिष्ट प्रदर्शन अनुकूलन

FibonacciReader के मामले में FibonacciReader हम प्रदर्शन को बेहतर बनाने के लिए अपने स्वयं के कार्यान्वयन को जोड़ सकते हैं ( फ़िबोनैचिरेडर के अंतिम संस्करण में। फाइल):



GetItemAt विधि इंटरफ़ेस में दिए गए डिफ़ॉल्ट कार्यान्वयन को ओवरराइड करती है।

यहां मैं उसी LINQ ElementAt विधि का उपयोग करता हूं जैसे कि डिफ़ॉल्ट कार्यान्वयन में। हालाँकि, मैं इस विधि का उपयोग केवल पढ़ने के संग्रह के साथ नहीं करता हूं जो GetItems लौटता है, बल्कि फाइबोनैचि असमानता के साथ, जो IEnumerable ।

चूंकि FibonacciSequence IEnumerable , इसलिए जैसे ही हम चयनित तत्व पर पहुंचते हैं, वैसे ही ElementAt कॉल समाप्त ElementAt । इसलिए, हम पूरे संग्रह को उत्पन्न नहीं करेंगे, लेकिन केवल सूचकांक में निर्दिष्ट स्थिति तक स्थित तत्व हैं।

इसे आज़माने के लिए, नियंत्रण बिंदु को छोड़ दें जो हमने आवेदन में ऊपर किया था और फिर से आवेदन चलाएँ। इस बार हम केवल एक बार ब्रेकपॉइंट पर ठोकर खाते हैं (जब GetItems )। GetItemAt कॉल करने पर ऐसा नहीं होगा।

एक छोटा सा उदाहरण

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

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

अपनी धारणाओं के बारे में सोचो

मान्यताएँ अपरिहार्य हैं। यदि हमने कोड में अपने पुस्तकालयों के किसी भी संभावित उपयोग के मामलों को ध्यान में रखने की कोशिश की, तो कोई भी कार्य कभी पूरा नहीं होगा। लेकिन आपको अभी भी कोड में मान्यताओं पर ध्यान से विचार करने की आवश्यकता है।

इसका मतलब यह नहीं है कि GetElementAt कार्यान्वयन आवश्यक रूप से खराब है। हां, इसके साथ संभावित प्रदर्शन के मुद्दे हैं। हालाँकि, यदि डेटा सेट छोटे हैं, या गणना किए गए तत्व "सस्ते" हैं, तो डिफ़ॉल्ट कार्यान्वयन एक उचित समझौता हो सकता है।

मैं, फिर भी, इंटरफ़ेस में बदलावों का स्वागत नहीं करता क्योंकि इसके पहले से ही कार्यान्वयनकर्ता हैं। लेकिन मैं समझता हूं कि ऐसे परिदृश्य भी हैं जिनमें वैकल्पिक विकल्प पसंद किए जाते हैं। प्रोग्रामिंग समस्याओं का समाधान है, और समस्याओं को हल करते समय प्रत्येक उपकरण और दृष्टिकोण में निहित पेशेवरों और विपक्षों को तौलना आवश्यक है।

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

अपने काम में गुड लक!