2009-09-07 22 views
14

सी # 3.5 में इंटरफेस को लागू करने के क्या फायदे हैं?इंटरफ़ेस को लागू करने के लाभ

+9

आप शायद सी # 3.0 का मतलब है। 3.5 .NET फ्रेमवर्क का संस्करण है। सी # में इंटरफ़ेस के लाभ संस्करण 1.0 के बाद से समान हैं। यह एक भारित सवाल है। आप Google या बिंग का उपयोग कर अपना जवाब पा सकते हैं। – Vadim

+0

हां, 3.0 कोशिश की गई खोज को कुछ भी नहीं मिला जो स्पष्ट लाभ प्रदान करता था। – DotNetRookie

+3

+1, मुझे नहीं लगता कि यह क्यों डाउनवॉटेड है। –

उत्तर

25

आप अपनी ऑब्जेक्ट को किसी विधि (या एक प्रकार की बाधा को पूरा करने) में पारित करने में सक्षम होंगे जो इंटरफ़ेस को तर्क के रूप में अपेक्षा करता है। सी # "duck typing" का समर्थन नहीं करता है। बस तरीकों इंटरफ़ेस द्वारा परिभाषित लिख कर, वस्तु स्वचालित रूप से इंटरफ़ेस प्रकार के साथ 'उपयुक्त' नहीं होगा:

public void PrintCollection<T>(IEnumerable<T> collection) { 
    foreach (var x in collection) 
     Console.WriteLine(x); 
} 

तो List<T>IEnumerable<T> इंटरफ़ेस को लागू नहीं किया है, आप के रूप में इसे पारित करने में सक्षम नहीं होगा PrintCollection विधि के लिए एक तर्क (भले ही उसके पास GetEnumerator विधि हो)।

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

+0

क्या आप एक उदाहरण प्रदान कर सकते हैं? – DotNetRookie

+1

असल में सी # संस्करण 4 के बाद से "बतख टाइपिंग" का समर्थन करता है। http://msdn.microsoft.com/en-us/library/dd264741.aspx लेकिन यह निश्चित रूप से इस परिदृश्य में इंटरफ़ेस का उपयोग करने का सबसे अच्छा समाधान है। विश्व भूख को हल करने के लिए – Tohid

10

यह मदद मिलेगी जब आप करने की कोशिश: स्टब्स/Mocks साथ

  • यूनिट परीक्षण
  • निर्भरता इंजेक्शन
  • दुनिया भूख का समाधान लागू

दया, (हालांकि यह अप्रमाणित!)

दान

+2

+1! युग्मन का उल्लेख करने के लिए \ o/ – Bombe

1

आप कक्षा विरासत से बंधे नहीं हैं - आप किसी भी कक्षा में एक इंटरफेस लागू कर सकते हैं। किसी भी वर्ग में कई इंटरफेस हो सकते हैं - सी # एकाधिक वर्ग विरासत का समर्थन नहीं करता है, यानी आप इंटरफेस

16

के माध्यम से एक अच्छा एब्स्ट्रक्शन लेयर प्रदान कर रहे हैं मुख्य लाभ कोड पठनीयता, कोड रखरखाव और कोड "अर्थशास्त्र" के बारे में है।

  • कोड पठनीयता: एक इंटरफेस इरादों के बारे में एक घोषणा का गठन किया। यह आपकी कक्षा की क्षमता को परिभाषित करता है, आपकी कक्षा क्या करने में सक्षम है। यदि आप आईएसओर्टेबल को लागू करते हैं तो आप स्पष्ट रूप से बता रहे हैं कि आपकी कक्षा को क्रमबद्ध किया जा सकता है, वही इरेंडरबल या आईकोनवर्टिबल के लिए।
  • कोड अर्थशास्त्र: इंटरफेस प्रदान करके और उन्हें लागू करने से आप एचटीएमएल और सीएसएस के समान तरीके से अवधारणाओं को सक्रिय रूप से अलग कर रहे हैं। एक वर्ग वास्तविक वस्तु वस्तुओं या अवधारणाओं के सामान्य गुणों को मॉडलिंग करके वास्तविकता का प्रतिनिधित्व करने के किसी भी तरीके "ऑब्जेक्ट क्लास" का एक ठोस कार्यान्वयन है। एक इंटरफेस एक व्यवहार मॉडल परिभाषित करता है, एक वस्तु क्या कर सकती है इसकी परिभाषा। उन अवधारणाओं को अलग करना आपके कोड के अर्थशास्त्र को और अधिक स्पष्ट रखता है। इस तरह से कुछ विधियों को पशु वर्ग के उदाहरण की आवश्यकता हो सकती है जबकि अन्य जो भी आप उन्हें "चलने" का समर्थन करते हैं, तब तक आप जो भी वस्तु फेंकते हैं उसे स्वीकार कर सकते हैं।
  • कोड रखरखाव: इंटरफेस युग्मन को कम करने में मदद करता है और इसलिए अंतर्निहित कोड प्रभावित होने के बिना आपको उसी अवधारणा के लिए आसानी से कार्यान्वयन करने की अनुमति देता है। इंटरफेस लागू करने वाली एक नई कक्षा को परिभाषित करके आप आसानी से एक इमेजेज के कार्यान्वयन को बदल सकते हैं। तुलना करें कि सीमेंस से सीएमवाई न्यू मैसेज क्लास के सभी संदर्भों को बदले में बदल दें।
+1

+1! – TrueWill

2

एक इंटरफेस एक अनुबंध (चीजें जो एक वस्तु करने में सक्षम है) परिभाषित करता है, जबकि एक ठोस वर्ग (या संरचना) ठोस व्यवहार को परिभाषित करता है।

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

1

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

4

इंटरफेस कोई वास्तविक लाभ प्रदान नहीं करते हैं। किसी भी इंटरफ़ेस के साथ किया जा सकता है, और अन्य भाषा निर्माण का उपयोग करके किया जाना चाहिए। एकाधिक विरासत को इंटरफेस का उपयोग करने से प्राप्त एकमात्र वास्तविक लाभ के रूप में उद्धृत किया गया है, लेकिन मैं सी # में बहुत आसानी से और स्पष्ट रूप से एकाधिक विरासत कर सकता हूं - मैं इसे हर दिन करता हूं। इंटरफेस को "तोड़ने" के बिना कोड बदलना सभी बहाने का सबसे अच्छा है ... यह कंक्रीट कक्षाओं के समान ही लागू होता है क्योंकि यह अमूर्त कक्षाओं या इंटरफेस के लिए होता है। जब तक कार्यात्मक हस्ताक्षर नहीं बदलता है, तब तक आपने इंटरफ़ेस को तोड़ दिया नहीं है। कोई फर्क नहीं पड़ता कि यह कहां घोषित किया गया था। बस एक अलग फ़ाइल में एक कार्यात्मक प्रोटोटाइप डालना और इसे "I" के साथ नामकरण करना कुछ भी नहीं खरीदता है - सिवाय इसके कि आप बनाए रखने के लिए कई स्रोत फ़ाइलों को दो बार समाप्त कर देते हैं। यह अनुमान है कि इंटरफ़ेस को प्रारंभिक रूप से परिभाषित किया गया है, और उसके बाद अनुबंध को हास्यास्पद बना दिया जाता है। इंटरफ़ेस विधियों और उनके पैरामीटर हर समय बदलते हैं, क्योंकि सब कुछ कभी-कभी ज्ञात नहीं होता है। यही कारण है कि माइक्रोसोफ ने बहुत पहले उनका उपयोग करना बंद कर दिया था। उनके पास IUnKnown, IUnknown2, आदि था। यह एक गड़बड़ पैदा की।

2

यदि आप एक विशाल, वाणिज्यिक सॉफ्टवेयर हाउस में काम करते हैं - तो आप इंटरफेस के न्यायिक उपयोग पर विचार करना चाहते हैं। अन्यथा, आपको उनसे दूर रहना चाहिए। बहु थ्रेडिंग के लिए वही। अगर मुझे एक और स्क्रिप्ट-किडी ऐप दिखाई देता है जो "हैलो वर्ल्ड" लिखने के लिए 20 थ्रेड बनाता है तो मैं सनकी हूं। बहु-थ्रेडिंग उन ऐप्स के लिए पूरी तरह से आरक्षित होनी चाहिए जिनकी आवश्यकता होती है, आमतौर पर एक बहु-प्रोसेसिंग वातावरण में। 90% समय से यह अच्छे से ज्यादा नुकसान पहुंचाता है। और थ्रेड हाईजैक/ऑफ-विषय टिप्पणियों से परेशान न हों। मुझे परवाह नहीं है मैं ज़्यादातर ज़िंदा रहने से ज़्यादा ऐसा कर रहा हूं। रैंक के अपने विशेषाधिकार हैं।

3

इंटरफेस का मुख्य लाभ ज्यादातर परियोजना डिजाइन से संबंधित है।

आप एक इंटरफेस का उपयोग करते हैं:

  1. इंटरफ़ेस का उपभोक्ता है कि इंटरफ़ेस को लागू करना चाहिए।
  2. डिजाइनिंग ब्रिज पैटर।
  3. अनुबंध बनाना ताकि उपयोगकर्ता को इंटरफ़ेस के नियमों का पालन करना पड़े।
  4. मुख्य कक्षा से केवल इंटरफ़ेस भाग (Object) ले सकते हैं।
  5. यहां तक ​​कि कक्षा निजी है,
  6. से इंटरफ़ेस ऑब्जेक्ट प्राप्त कर सकते हैं एकाधिक विरासत की शैली।
  7. लागू करने की आवश्यकता नहीं है, यदि लागू हो तो इसका मतलब है कि यदि आप चाहते हैं कि आप इसे अन्यथा लागू कर सकते हैं तो इसे छोड़ सकते हैं ..
  8. क्लीनर कोड।
  9. कार्यान्वयन जो कक्षा में निर्भर करता है, इंटरफ़ेस के साथ आगे बढ़ सकता है।
  10. यदि प्रत्येक वर्ग में इंटरफेस के लिए जाने के लिए बेहतर तरीके से एक विधि का अलग कार्यान्वयन होता है। उदाहरण के लिए संग्रह में IEnumerable

सी # आर्किटेक्ट के अनुसार, एक साधारण शब्द में यह एक अनुबंध है। उपभोक्ता को इसका पालन करना होगा।

0

तरह से मैं समझता हूँ कि यह इंटरफेस इन मामलों में सबसे उपयोगी होते हैं:

  1. क्लीनर प्रोग्रामर के बीच श्रम विभाजन। लीड प्रोग्रामर इंटरफेस लिखता है और कनिष्ठ प्रोग्रामर इसके कार्यान्वयन लिखता है। यह मेरे लिए सही समझ में आता है। हालांकि लीड प्रोग्रामर इंटरफेस के बजाय छद्म कोड लिख सकता है।

  2. कुछ विशिष्ट स्थिति, जहां आपको एक ही कक्षा के 2 या अधिक विभिन्न कार्यान्वयन की आवश्यकता होती है, उदाहरण के लिए इंटरफ़ेस पशु और कक्षाएं बाघ और शेर इसका उपयोग करते हैं। और यहां तक ​​कि यह बहुत समझ में नहीं आता है, क्योंकि शेरों और बाघ कुछ चीजों को साझा करते हैं। सार वर्ग बेहतर होगा, क्योंकि यदि आप इंटरफ़ेस का उपयोग करते हैं तो आपको अलग-अलग वर्गों में सामान्य फ़ंक्शन लिखना होगा जो कोड डुप्लिकेशन का कारण बनता है, जो खराब है।

  3. आप एक पुस्तकालय लिखते हैं और इसे उपयोगकर्ताओं द्वारा संशोधित करना चाहते हैं। तो आप इंटरफेस और इसके वर्ग कार्यान्वयन लिखते हैं। आपके lib के उपयोगकर्ता के पास अभी भी अपनी कार्यान्वयन कक्षा लिखने की संभावना है, जो विभिन्न तकनीक/एल्गोरिदम का उपयोग कर सकती है जो एक ही परिणाम प्राप्त करती है, लेकिन शायद उदाहरण के लिए एक तेज़ तरीके से। यही कारण है कि हम उन प्रयोगों में इतने सारे इंटरफेसों को पूरा करते हैं जिनका हम उपयोग करते हैं, लेकिन शायद ही कभी अपने स्वयं के इंटरफेस लिखने की आवश्यकता महसूस होती है। क्योंकि हम पुस्तकालयों को नहीं लिखते हैं।

संबंधित मुद्दे