🏭 🏨 🏜️ .Net में इंटरफेस के बारे में थोड़ा (एक साक्षात्कार के आधार पर) 📨 🤟🏾 📳

पिछले सोमवार, मैं भाग्यशाली था कि एक अंतरराष्ट्रीय कंपनी में वरिष्ठ। नेट डेवलपर पर एक साक्षात्कार प्राप्त किया। साक्षात्कार के दौरान, मुझे एक परीक्षा लेने के लिए कहा गया, जहाँ कई प्रश्न .Net से संबंधित थे। विशेष रूप से, किसी एक प्रश्न में कई कथनों का मूल्यांकन (सत्य / असत्य) देना आवश्यक था, जिनमें निम्न थे:

.Net में, तत्वों के किसी भी सरणी, उदाहरण के लिए int [], डिफ़ॉल्ट रूप से IList को लागू करता है, जो आपको फ़ॉरच कथन में संग्रह के रूप में इसका उपयोग करने की अनुमति देता है।

जल्दी से इस सवाल का जवाब नकारात्मक रूप से और अलग से हाशिये में जोड़ना। उस फॉर्च्यूनर को आईलिस्ट के कार्यान्वयन की आवश्यकता होती है, लेकिन IEnumerable की, मैं अगले प्रश्न पर गया। हालांकि, घर के रास्ते पर, मुझे इस सवाल से परेशान किया गया था: क्या सरणी अभी भी इस इंटरफ़ेस को लागू करती है या नहीं?

IList के बारे में, मैंने अस्पष्ट रूप से याद किया कि इस इंटरफ़ेस ने मुझे एक IEnumerable, एक अनुक्रमणिका, और एक गणना गुण दिया जिसमें संग्रह में तत्वों की संख्या थी, साथ ही साथ शायद ही कभी उपयोग किए जाने वाले गुणों के एक जोड़े, जैसे कि IsFixedChlection ()। सरणी में इसके आकार के लिए लंबाई की संपत्ति है, और IEnumerable में गणना LINQ से एक विस्तार विधि है, जो इस पद्धति को कक्षा में लागू किए जाने पर संभव नहीं होगा। इस प्रकार, यह पता चला कि सरणी IList इंटरफ़ेस को लागू नहीं कर सकती थी, हालांकि, कुछ अस्पष्ट भावना ने मुझे परेशान किया। इसलिए, साक्षात्कार के बाद शाम में, मैंने थोड़ा शोध करने का फैसला किया।

कक्षा प्रणाली

चूँकि Reflector.Net मेरे लिए स्थापित नहीं थी, इसलिए मैंने यह जानने के लिए C # में एक छोटा प्रोग्राम लिखा कि एक पूर्णांक सरणी द्वारा क्या इंटरफेस लागू किए गए हैं।

var v = new int[] { 1, 2, 3 }; var t = v.GetType(); var i = t.GetInterfaces(); foreach(var tp in i) Console.WriteLine(tp.Name);

यहाँ कंसोल विंडो से प्राप्त इंटरफेस की पूरी सूची है:

 ICloneable IList ICollection IEnumerable IStructuralComparable IStructuralEquatable IList`1 ICollection`1 IEnumerable`1 IReadOnlyList`1 IReadOnlyCollection`1

इस प्रकार, .Net में एक सरणी अभी भी IList इंटरफ़ेस और इसके ILI <के सामान्य संस्करण को लागू करती है ।

अधिक संपूर्ण जानकारी प्राप्त करने के लिए, मैंने System.Array क्लास का आरेख बनाया।

मेरी गलती ने मुझे तुरंत मार दिया: गणना IList की संपत्ति नहीं थी, लेकिन ICollection, वंशानुक्रम श्रृंखला में एक और पिछला इंटरफ़ेस था। हालाँकि, सरणी में पहले से ही ऐसी संपत्ति नहीं थी, जो IList इंटरफ़ेस के कई अन्य गुणों के रूप में थी, हालाँकि इस इंटरफ़ेस के अन्य गुणों, IsFixedSize और IsReadOnly को लागू किया गया था। यह कैसे भी संभव है?

जब आप याद करते हैं कि C # में सब कुछ तुरंत गिर जाता है, तो आप न केवल इंटरफेस को लागू कर सकते हैं
स्पष्ट रूप से, लेकिन यह भी स्पष्ट रूप से। मुझे पाठ्यपुस्तकों से इस संभावना के बारे में पता था, जिसने मामले में इस तरह के कार्यान्वयन का एक उदाहरण दिया। जब बेस क्लास में पहले से ही इंटरफ़ेस विधि नाम के साथ एक विधि होती है। ऐसा मौका मैंने ReSharper में भी देखा था। हालांकि, आज तक, मुझे सीधे अपनी परियोजनाओं में स्पष्ट रूप से इंटरफेस को लागू करने की आवश्यकता से निपटने की आवश्यकता नहीं है।

इंटरफेस के स्पष्ट और निहित कार्यान्वयन की तुलना

चलो इंटरफेस के कार्यान्वयन के इन दो प्रकारों की तुलना करते हैं:।

मापदंड	निष्प्राण क्रियान्वयन	स्पष्ट कार्यान्वयन
मूल वाक्य रचना	`interface ITest { void DoTest(); } public class ImplicitTest : ITest { public void DoTest() { } }`	`interface ITest { void DoTest(); } public class ExplicitTest : ITest { void ITest.DoTest() { } }`
दृश्यता	लागू कार्यान्वयन हमेशा सार्वजनिक रहा है, इसलिए विधियों और गुणों को सीधे एक्सेस किया जा सकता है। `var imp = new ImplicitTest(); imp.DoTest();`	स्पष्ट कार्यान्वयन हमेशा बंद (निजी) होता है। कार्यान्वयन तक पहुंच प्राप्त करने के लिए, आपको कक्षा के उदाहरण को इंटरफ़ेस (इंटरफ़ेस तक अपकास्ट) में डालना होगा। `var exp = new ExplicitTest(); ((ITest)exp).DoTest();`
polymorph	अंतर्निहित इंटरफ़ेस कार्यान्वयन आभासी हो सकता है, जो आपको वंशजों में इस कार्यान्वयन को फिर से लिखने की अनुमति देता है।	स्पष्ट कार्यान्वयन हमेशा स्थिर होता है। नए वंशजों में इसे ओवरराइड या ओवरराइड नहीं किया जा सकता है। ^{लगभग।} ¹
सार वर्ग और कार्यान्वयन	कार्यान्वयन को अमूर्त किया जा सकता है और केवल वंशज वर्ग में लागू किया जा सकता है।	एक स्पष्ट कार्यान्वयन अमूर्त नहीं हो सकता है, लेकिन कक्षा में स्वयं अन्य सार विधियां हो सकती हैं और स्वयं अमूर्त हो सकती हैं। ^{लगभग।} ²

टिप्पणी:
^{लगभग।} ¹ - जैसा कि महापौर सही ढंग से टिप्पणियों में देखते हैं, कार्यान्वयन को वंशज वर्ग में इंटरफ़ेस के बार-बार स्पष्ट कार्यान्वयन द्वारा ओवरराइड किया जा सकता है (लेख पर पहली टिप्पणी देखें)।

^{लगभग।} ² - ब्लॉग में से एक ने संकेत दिया कि वर्ग ही सार नहीं हो सकता है। शायद यह संकलक के पिछले संस्करणों में से कुछ के लिए सच था, मेरे प्रयोगों में मैं आसानी से एक अमूर्त वर्ग में इंटरफ़ेस को आसानी से लागू कर सकता था।

हमें इंटरफेस के स्पष्ट कार्यान्वयन की आवश्यकता क्यों है?

MSDN के अनुसार एक स्पष्ट इंटरफ़ेस कार्यान्वयन आवश्यक है, जब एक वर्ग द्वारा लागू किए गए कई इंटरफेस एक ही हस्ताक्षर के साथ एक विधि है। यह समस्या आम तौर पर अंग्रेजी बोलने वाली दुनिया में चिलिंग नाम "मौत के घातक हीरे" के तहत जानी जाती है , जो रूसी में "हीरे की समस्या" के रूप में तब्दील हो जाती है। यहाँ ऐसी स्थिति का एक उदाहरण है:

 /* Listing 1 */ interface IJogger { void Run(); } interface ISkier { void Run(); } public class Athlete: ISkier, IJogger { public void Run() { Console.WriteLine("Am I an Athlete, Skier or Jogger?"); } }

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

 /* Listing 2 */ var sp = new Athlete(); sp.Run(); (sp as ISkier).Run(); (sp as IJogger).Run();

इस कोड का परिणाम तीन बार सांत्वना में प्रदर्शित "क्या मैं एक एथलीट, स्कीयर या जॉगर?" होगा ।

यह यहां है कि हम सभी तीन मामलों को अलग करने के लिए इंटरफ़ेस के स्पष्ट कार्यान्वयन का उपयोग कर सकते हैं:

 /* Listing 3 */ public class Sportsman { public virtual void Run() { Console.WriteLine("I am a Sportsman"); } } public class Athlete: Sportsman, ISkier, IJogger { public override void Run() { Console.WriteLine("I am an Athlete"); } void ISkier.Run() { Console.WriteLine("I am a Skier"); } void IJogger.Run() { Console.WriteLine("I am a Jogger"); } }

इस स्थिति में, जब कोड 2 से कोड निष्पादित किया जाता है, तो हम कंसोल में तीन लाइनें देखेंगे, "मैं एक एथलीट हूं " , "मैं एक स्कीयर हूं " और "मैं एक जॉगर हूं" ।

विभिन्न इंटरफ़ेस कार्यान्वयन के पेशेवरों और विपक्ष

कार्यान्वयन दृश्यता और कस्टम कार्यान्वयन

जैसा कि ऊपर दिखाया गया है, एक अंतर्निहित कार्यान्वयन सामान्य वर्ग विधि से अलग-अलग रूप से अलग नहीं है (यदि इस विधि को पूर्वज वर्ग में पहले से ही परिभाषित किया गया है, तो इस वाक्यविन्यास में विधि वंश में छिपी होगी और कोड को किसी भी समस्या के लिए संकलित किया जाएगा c संकलक विधि को छिपाने के बारे में चेतावनी।)। इसके अलावा, एक इंटरफ़ेस के अलग-अलग तरीकों का चयनात्मक कार्यान्वयन स्पष्ट रूप से और अंतर्निहित रूप से दोनों संभव है:

 /* Listing 4 */ public class Code { public void Run() { Console.WriteLine("I am a class method"); } } interface ICommand { void Run(); void Execute(); } public class CodeCommand : Code, ICommand { // implicit interface method implementation // => public implementation // implicit base class method hiding (warning here) public void Run() { base.Run(); } // explicit interface method implementation // => private implementation void ICommand.Execute() {} }

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

दूसरी ओर, तरीकों के निजी कार्यान्वयन की संभावना आपको इसे लागू करने के दौरान कई इंटरफ़ेस विधियों को छिपाने की अनुमति देती है। .Net में सरणियों के साथ अपने पहले पहले उदाहरण पर लौटते हुए, हम देख सकते हैं कि सरणी छिपती है, उदाहरण के लिए, ICollection इंटरफ़ेस की गणना संपत्ति का कार्यान्वयन, नाम लंबाई के तहत इस संपत्ति को उजागर करना (यह संभवतः C ++ STL और Java के साथ बनाए रखने का प्रयास है)। इस प्रकार, हम कार्यान्वित इंटरफ़ेस के कुछ तरीकों को छिपा सकते हैं और दूसरों को नहीं छिपा सकते हैं (= सार्वजनिक करते हैं)।

यहाँ, हालांकि, इस तरह की समस्या उत्पन्न होती है कि कई मामलों में यह अनुमान लगाना पूरी तरह से असंभव है कि वर्ग "निहित" द्वारा कौन से इंटरफेस को लागू किया जाता है, क्योंकि इंटेलीजेंसी में न तो तरीके और न ही इन इंटरफेस के गुण दिखाई देते हैं (उदाहरण के लिए System.Aray यहां भी सांकेतिक है)। इस तरह के कार्यान्वयन का पता लगाने का एकमात्र तरीका दृश्य स्टूडियो में ऑब्जेक्ट ब्राउज़र का उपयोग करके, प्रतिबिंब का उपयोग करना है।

इंटरफ़ेस रीफैक्टरिंग

चूँकि इंटरफेस को लागू करने (पब्लिक) का कार्यान्वयन पब्लिक क्लास मेथड के इम्प्लीमेंटेशन से अलग नहीं होता है, इंटरफ़ेस को रिफ़्लेक्ट करने और उसमें से कुछ पब्लिक मेथड हटाने के मामले में (उदाहरण के लिए, जब रन) () और एक्सिक्यूट () मेथड्स को उपरोक्त ICommand इंटरफ़ेस से एक रन ( )) सभी निहित कार्यान्वयनों में, एक खुली पहुंच विधि बनी रहेगी, जो कि रिफैक्टरिंग के बाद भी समर्थित होने की बहुत संभावना है, क्योंकि इस सार्वजनिक पद्धति में सिस्टम के अन्य घटकों में पहले से ही अलग-अलग निर्भरता हो सकती है। इसके परिणामस्वरूप, प्रोग्रामिंग सिद्धांत "इंटरफेस के खिलाफ, कार्यान्वयन नहीं" का उल्लंघन किया जाएगा, क्योंकि निर्भरताएं पहले से ही पूर्व इंटरफेस विधि के विशिष्ट (और विभिन्न वर्गों में, संभवतः अलग-अलग) कार्यान्वयनों के बीच होंगी।

 /* Listing 5 */ interface IFingers { void Thumb(); void IndexFinger(); // an obsolete interface method // void MiddleFinger(); } public class HumanPalm : IFingers { public void Thumb() {} public void IndexFinger() {} // here is a "dangling" public method public void MiddleFinger() {} } public class AntropoidHand : IFingers { void IFingers.Thumb() {} void IFingers.IndexFinger() {} // here the compiler error void IFingers.MiddleFinger() {} }

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

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

 /* Listing 6 */ interface IProperty { int Amount { get; set; } } public class ClassWithProperty : IProperty { // implicit implementation, public public int Amount { get; set; } public ClassWithProperty() { // internal invocation of the public setter Amount = 1000; } } public class ClassWithExplicitProperty : IProperty { // explicit implementation, private int IProperty.Amount { get; set; } public ClassWithExplicitProperty() { // internal invocation isn't possible // compiler error here Amount = 1000; } }

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

स्थानीय चर और वर्ग फ़ील्ड के स्पष्ट प्रकार का उपयोग करना

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

इस प्रकार, एक ओर, हम कोड को कुछ हद तक लचीला बनाते हैं (उदाहरण के लिए, ReSharper हमेशा संभव हो तो var के साथ एक घोषणा का उपयोग करने का सुझाव देता है), लेकिन हम एक विशिष्ट कार्यान्वयन के लिए बाध्यकारी से जुड़ी संभावित समस्याओं से बचते हैं क्योंकि सिस्टम बढ़ता है और इसका आकार बढ़ता है। कोड। यह बिंदु बहुत विवादास्पद लग सकता है, लेकिन इस मामले में जब कई लोग परियोजना पर काम कर रहे हैं, और यहां तक कि दुनिया के विभिन्न हिस्सों में, स्पष्ट टाइपिंग का उपयोग करना बहुत उपयोगी हो सकता है, क्योंकि इससे कोड की पठनीयता बढ़ जाती है और इसे बनाए रखने की लागत कम हो जाती है।

संबंधित सूत्र

लेख को तैयार करने में, कई नेटवर्क स्रोतों से जानकारी का उपयोग किया गया था, विशेष रूप से ब्लॉगों से ( [1] , [2] , [3] और [4] ), साथ ही स्टैकऑवरफ़्लो से [5] और [6] सवालों का एक बहुत ही दिलचस्प लेख । कोडप्रोजेक्ट और अध्याय 13.5 जेफरी रिक्टर के " सीएलआर विद सी # "।

एक छोटा सा बोनस: बैकफिलिंग के लिए दो प्रश्न (जिज्ञासु के लिए)

ये प्रश्न सीधे तौर पर इंटरफेस के स्पष्ट कार्यान्वयन के विषय से संबंधित नहीं हैं, लेकिन मुझे ऐसा लगता है कि यहां वे किसी के लिए रुचि रखते हैं:
1. यदि सूची 2 में दूसरी पंक्ति शामिल है

 (sp as Sportsman).Run();

कंसोल में क्या प्रदर्शित किया जाएगा?

2. लिस्टिंग 3 में न्यूनतम बदलाव (दूसरे के साथ एक कीवर्ड की जगह) का उपयोग करते हुए कंसोल के पहले प्रश्न में मैं "मैं एक खिलाड़ी हूं" वाक्यांश कैसे प्राप्त कर सकता हूं ?

.Net में इंटरफेस के बारे में थोड़ा (एक साक्षात्कार के आधार पर)