इंटरफ़ेस बनाने के लिए मुझे कैसे पता चलेगा?

196

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

मैं अक्सर उनके बारे में पढ़ता हूं लेकिन ऐसा लगता है जैसे मैं उन्हें समझ नहीं सकता।

मैंने ऐसे उदाहरण पढ़े हैं: पशु आधार वर्ग, 'वॉक', 'रन', 'गेटलेग्स', आदि जैसी चीजों के लिए IAnimal इंटरफ़ेस के साथ - लेकिन मैंने कभी किसी चीज़ पर काम नहीं किया है और मुझे ऐसा महसूस हुआ है कि "मुझे एक इंटरफ़ेस का उपयोग करना चाहिए" यहाँ!"

मैं क्या खो रहा हूँ? मेरे लिए समझाना इतना कठिन क्यों है! मैं सिर्फ इस तथ्य से भयभीत हूं कि मुझे कभी भी एक ठोस आवश्यकता का एहसास नहीं हो सकता है - ज्यादातर उन्हें समझने के कुछ लापता पहलू के कारण! यह मुझे महसूस करता है कि मैं एक डेवलपर होने के मामले में शीर्ष पर कुछ याद कर रहा हूं! अगर किसी को इस तरह का अनुभव हुआ है और एक सफलता मिली है तो मैं इस अवधारणा को समझने के कुछ सुझावों की सराहना करूंगा। धन्यवाद।

— user53885
स्रोत

1

आपको बाहर की जाँच

— करनी

151

यह इस ठोस समस्या को हल करता है:

आपके पास 4 अलग-अलग प्रकारों के ए, बी, सी, डी हैं। आपके कोड में सब कुछ आपके पास है जैसे:

a.Process();
b.Process();
c.Process();
d.Process();

क्यों नहीं उन्होंने IProcessable को लागू किया है, और फिर करते हैं

List<IProcessable> list;

foreach(IProcessable p in list)
    p.Process();

जब आप जोड़ते हैं, तो यह बेहतर होगा, 50 प्रकार के वर्ग, जो सभी एक ही काम करते हैं।

एक और ठोस समस्या:

क्या आपने कभी System.Linq.Enumerable पर एक नज़र डाली है? यह विस्तार के तरीकों की एक टन को परिभाषित करता है जो IEnumerable को लागू करने वाले किसी भी प्रकार पर संचालित होता है। क्योंकि कुछ भी जो IEnumerable को लागू करता है, वह मूल रूप से कहता है कि "मैं एक अव्यवस्थित फ़ॉरेस्ट-प्रकार पैटर्न में पुनरावृत्ति का समर्थन करता हूं", आप किसी भी गणना योग्य प्रकार के लिए जटिल व्यवहार (गणना, अधिकतम, कहां, चयन, आदि) को परिभाषित कर सकते हैं।

— सर्व-कुंची
स्रोत

2

वह मदद करता है। प्रक्रिया () विधि के लिए लागू सभी प्रकार के बजाय एक इंटरफ़ेस मौजूद होने का क्या फायदा है?

— user53885

जब तक वे एक ही आधार प्रकार के सभी उपवर्ग नहीं थे, तब तक आप एक ही चर p का उपयोग करने में सक्षम होंगे, या उन्होंने इंटरफ़ेस लागू किया।

— कार्ल

आपको प्रक्रिया विधि के साथ 50 विभिन्न वर्गों के विपरीत, कास्ट नहीं करना है। C # "बतख टाइपिंग" का उपयोग नहीं करता है, इसलिए सिर्फ इसलिए कि A में प्रोसेस है () और B में प्रोसेस है () का मतलब यह नहीं है कि कॉल करने का कोई सामान्य तरीका है। उसके लिए आपको एक इंटरफ़ेस चाहिए।

— user7116

सही। मैंने उदाहरण के लिए और अधिक अर्थ बनाने के लिए "var" को "IProcessable" में बदल दिया।

— जिमी

2

@Rogerio: मैं सामान्य होने की कोशिश कर रहा था। मुद्दा यह नहीं है कि "जब आपके पास ऐसी चीजें हैं जिनके पास एक प्रक्रिया है () फ़ंक्शन" यह "है जब आपके पास ऐसी चीजें होती हैं जो तरीकों का एक सामान्य सेट साझा करती हैं"। उदाहरण को आसानी से बदला जा सकता हैforeach(IMyCompanyWidgetFrobber a in list) a.Frob(widget, context);

— जिमी

133

मुझे जिमी का जवाब बहुत पसंद है, लेकिन मुझे लगता है कि मुझे इसमें कुछ जोड़ने की जरूरत है। पूरी बात करने के लिए कुंजी "सक्षम" IProcess में है सक्षम। यह एक क्षमता (या संपत्ति, लेकिन अर्थ "आंतरिक गुणवत्ता" को इंगित करता है, न कि उस वस्तु के C # गुणों के अर्थ में) जो इंटरफ़ेस को लागू करता है। IAnimal शायद एक इंटरफ़ेस के लिए एक अच्छा उदाहरण नहीं है, लेकिन IWalkable के लिए एक अच्छा इंटरफ़ेस हो सकता है अगर आपके सिस्टम में कई चीजें हैं जो चल सकती हैं। आपके पास डॉग, काउ, फिश, स्नेक जैसे एनीमल से प्राप्त कक्षाएं हो सकती हैं। पहले दो शायद IWalkable को लागू करेंगे, बाद के दो नहीं चलते हैं, इसलिए वे नहीं करेंगे। अब आप पूछते हैं कि "सिर्फ एक और सुपरक्लास ही क्यों न हो, वॉकिंगएनिमल, कि डॉग एंड काउ से व्युत्पन्न?"। इसका उत्तर यह है कि जब आपके पास विरासत के पेड़ के बाहर पूरी तरह से कुछ है जो एक रोबोट जैसे चल सकता है। रोबोट IWalkable को लागू करेगा, लेकिन शायद पशु से प्राप्त नहीं होगा। यदि आप उन चीजों की सूची चाहते हैं, जो चल सकती हैं,

अब IWalkable को IPersistable जैसे कुछ और सॉफ्टवेयर-वाई के साथ बदलें, और सादृश्य आप एक वास्तविक कार्यक्रम में जो देखेंगे, उसके बहुत करीब हो जाता है।

— rmeador
स्रोत

9

मुझे पसंद है कि आप क्या आए - "यह एक क्षमता को इंगित करता है"। जब आपको क्षमता को परिभाषित करना होता है तो इंटरफेस की वास्तव में आवश्यकता होती है क्योंकि मूल बातें अपने "बेस" वर्ग से चिपकी रहती हैं।

— रमिज उद्दीन

72

जब समान कार्यक्षमता के कार्यान्वयन अलग-अलग होंगे, तो इंटरफेस का उपयोग करें।

जब आपको एक सामान्य कंक्रीट कार्यान्वयन को साझा करने की आवश्यकता होती है, तो एक सार / बेस कक्षाओं का उपयोग करें।

— तत्त्व
स्रोत

8

पहले एक को बहुरूपता कहा जाता है। दूसरा एक साँप का तेल है - जब तक कि उपवर्ग बेसकलैस नहीं है (इसमें लिस्कोव प्रतिस्थापन सिद्धांत का कोई उल्लंघन नहीं है), आपको विरासत पर रचना का पक्ष लेना चाहिए।

— अर्निस लैप्सा

@ अर्निसलैप्सा मुझे काफी समझ में नहीं आया कि "सबलेकस बेसकलैस होने तक" से आपका क्या मतलब है। जब एक उपवर्ग "बेसकेल्स" नहीं होगा? (जैसा कि isकीवर्ड में है)

— Marc.2377

32

एक अनुबंध की तरह एक इंटरफ़ेस के बारे में सोचो। यह कहने का एक तरीका है, "इन वर्गों को नियमों के इन सेटों का पालन करना चाहिए।"

इसलिए IAnimal उदाहरण में, यह कहने का एक तरीका है, "मैं उन कक्षाओं को चलाने में सक्षम होना चाहिए, जो IAnimal को लागू करते हैं।"

यह क्यों उपयोगी है? आप एक फ़ंक्शन का निर्माण करना चाह सकते हैं जो इस तथ्य पर निर्भर करता है कि आपको रन और वॉक को कॉल करने में सक्षम होना चाहिए, उदाहरण के लिए, ऑब्जेक्ट पर। आपके पास निम्नलिखित हो सकते हैं:

public void RunThenWalk(Monkey m) {
    m.Run();
    m.Walk();
}

public void RunThenWalk(Dog d) {
    d.Run();
    d.Walk();
}

... और सभी वस्तुओं को दोहराएं जिन्हें आप जानते हैं कि वे चल सकते हैं और चल सकते हैं। हालाँकि, आपके IAnimal इंटरफ़ेस के साथ, आप फ़ंक्शन को एक बार निम्नानुसार परिभाषित कर सकते हैं:

public void RunThenWalk(IAnimal a) {
    a.Run();
    a.Walk();
}

इंटरफ़ेस के खिलाफ प्रोग्रामिंग करके, आप अनिवार्य रूप से इंटरफ़ेस के इरादे को लागू करने के लिए कक्षाओं पर भरोसा कर रहे हैं। तो हमारे उदाहरण में, यह विचार है कि "मुझे परवाह नहीं है कि वे कैसे चलते हैं और चलते हैं, इसलिए जब तक वे चलते हैं और चलते हैं। मेरा RunThenWalk तब तक मान्य होगा जब तक वे उस समझौते को पूरा नहीं करते हैं। यह पूरी तरह से अच्छी तरह से काम करता है। कक्षा।"

इस संबंधित प्रश्न में एक अच्छी चर्चा भी है ।

— Larsenal
स्रोत

1

कार्यान्वयन स्वतंत्रता के बारे में मत भूलना। एक इंटरफ़ेस यह परवाह नहीं करता है कि अंतर्निहित फ़ंक्शन कैसे लागू किया जाता है, बस यह वही करता है जो इंटरफ़ेस कहता है।

— मैथ्यू ब्रूकर

18

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

उदाहरण मैं हमेशा किसी को देता हूं यदि आपके पास सेलबोट क्लास और वाइपर क्लास है। उन्हें क्रमशः बोट क्लास और कार क्लास विरासत में मिली हैं। अब कहते हैं कि आपको इन सभी वस्तुओं के माध्यम से लूप करने की आवश्यकता है और उनकी Drive()विधि को कॉल करें । जब आप निम्नलिखित की तरह कुछ कोड लिख सकते हैं:

if(myObject is Boat)
    ((Boat)myObject).Drive()
else
    if (myObject is Car)
        ((Car)myObject).Drive()

यह लिखना बहुत सरल होगा:

((IDrivable)myObject).Drive()

— स्पेंसर रूपर्ट
स्रोत

16

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

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

— कार्ल
स्रोत

15

मुझे सेना की उपमा पसंद है।

यदि आप एक सॉफ्टवेयर डेवलपर , संगीतकार या वकील हैं , तो सार्जेंट परवाह नहीं करता है ।
आपको सिपाही माना जाता है ।

यूएमएल

यह सार्जेंट के लिए आसान है कि वह उन व्यक्तियों के विशिष्ट विवरण से परेशान न हो, जिनके साथ वह काम कर रहा है,
सभी को सैनिक सार के रूप में मानते हैं (... और उन्हें दंडित करते हैं जब वे उनके जैसा कार्य करने में विफल होते हैं)।

व्यक्तियों के लिए सैनिकों की तरह कार्य करने की क्षमता को बहुरूपता कहा जाता है।

इंटरफेस सॉफ्टवेयर निर्माण हैं जो बहुरूपता को प्राप्त करने में मदद करते हैं।

सादगी प्राप्त करने के लिए अमूर्त विवरण की आवश्यकता है जो आपके प्रश्न का उत्तर है।

बहुरूपता , जिसका अर्थ है "कई रूपों" का अर्थ है, बेस क्लास के किसी भी उपवर्ग के एक ऑब्जेक्ट का इलाज करने की क्षमता है जैसे कि यह बेस क्लास की वस्तु थी। एक बेस क्लास है, इसलिए, कई रूप हैं: बेस क्लास ही, और इसके किसी भी उपवर्ग।

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

— आर्निस लैप्सा
स्रोत

14

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

कई अन्य कारण हैं जो मैंने इंटरफेस को रीफ्रैक्ट करने के अच्छे अभ्यास को सुदृढ़ करने के लिए पाया है, लेकिन यूनिट टेस्टिंग / मॉकिंग बात यह थी कि व्यावहारिक अनुभव का अंतर "अहा पल" प्रदान किया गया था।

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

— tvanfosson
स्रोत

गलत कारणों के लिए सही बात। आपके मामले में - आप तथाकथित "हेडर इंटरफेस" के साथ समाप्त होते हैं और अतिरिक्त जटिलता से अधिक वजन को सरलता प्राप्त करते हैं।

— अर्निस लैप्सा

@ अरनी - इकाई परीक्षण एक "गलत कारण" है, आसानी से परीक्षण में निर्भरता को दूर करने के लिए कक्षाओं का मजाक बनाना "गलत कारण" है। क्षमा करें, लेकिन मैं असहमत हूं।

— tvanfosson

1

यदि परीक्षण कोड है या परीक्षण योग्य नहीं है, तो परीक्षण अप्रत्यक्ष रूप से डिजाइन को प्रभावित करता है । एक्स्टेंसिबिलिटी को जोड़ना टेस्टिबिलिटी को बेहतर बनाने के लिए खुद को धोखा देने जैसा है। मैं मार्क सीमैन यह सबसे अच्छा योग लगता bit.ly/esi8Wp

— आर्निस Lapsa

1

@ अर्निस - तो क्या आप अपने यूनिट परीक्षणों में नकली का उपयोग करते हैं? यदि नहीं, तो आप निर्भरता पर निर्भरता कैसे हटाते हैं। क्या आप DI का उपयोग कर रहे हैं? यूनिट परीक्षण ने मॉकिंग और डीआई का उपयोग करने के लिए मुझे निकाल दिया; मॉकिंग और डीआई ने अनुबंधों को इस तरह परिभाषित करने के लिए इंटरफेस का उपयोग करने के अच्छे अभ्यास के लायक साबित किया जो कि कोई भी शैक्षणिक समझ कभी भी नहीं कर सकती थी। TDD को अपनाने के कारण, मेरा कोड इससे बहुत कम युग्मित है, अन्यथा नहीं होता। मुझे लगता है कि यह अच्छी बात है।

— tvanfosson

बस यह कहना कि अपघटन जो तथाकथित प्राकृतिक जोड़ों के साथ नहीं है, कम सामंजस्य और अनावश्यक जटिलता की ओर जाता है।

— अर्निस लैप्सा

10

कुछ गैर-प्रोग्रामिंग उदाहरण जो आपको प्रोग्रामिंग में इंटरफेस के उचित उपयोग को देखने में मदद कर सकते हैं।

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

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

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

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

5

यह पूरी तरह से एक .net डेवलपर के रूप में अपने पूरे जीवन को जाने के लिए संभव है और कभी भी अपना स्वयं का इंटरफेस न लिखें। आखिरकार, हम दशकों तक उनके बिना ठीक रहे और हमारी भाषाएं अभी भी ट्यूरिंग-पूर्ण थीं।

मैं आपको यह नहीं बता सकता कि आपको इंटरफेस की आवश्यकता क्यों है, लेकिन मैं आपको अपनी वर्तमान परियोजना में इनका उपयोग करने की सूची दे सकता हूं:

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

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

— हां - वह जेक।
स्रोत

5

एक कोड उदाहरण (एंड्रयू का एक अतिरिक्त के साथ - मेरा -का-जो उद्देश्य-के-इंटरफेस पर एक अतिरिक्त है ), यह भी इस बात पर एक केस बनाता है कि भाषाओं पर एक सार वर्ग के बजाय एकाधिक वंशानुक्रम के लिए कोई समर्थन नहीं है (c # और जावा):

interface ILogger
{
    void Log();
}
class FileLogger : ILogger
{
    public void Log() { }
}
class DataBaseLogger : ILogger
{
    public void Log() { }
}
public class MySpecialLogger : SpecialLoggerBase, ILogger
{
    public void Log() { }
}

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

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

— eglasius
स्रोत

4

मैंने अभी और फिर इंटरफेस का उपयोग किया है और यहाँ मेरा नवीनतम उपयोग (नाम सामान्यीकृत किया गया है):

मेरे पास एक WinForm पर कस्टम नियंत्रणों का एक गुच्छा है जो मेरे व्यावसायिक ऑब्जेक्ट को डेटा को बचाने की आवश्यकता है। प्रत्येक नियंत्रण को अलग से कॉल करने के लिए एक दृष्टिकोण है:

myBusinessObject.Save(controlA.Data);
myBusinessObject.Save(controlB.Data);
myBusinessObject.Save(controlC.Data);

इस कार्यान्वयन के साथ समस्या यह है कि किसी भी समय मैं एक नियंत्रण जोड़ता हूं मुझे अपने "डेटा सहेजें" विधि में जाना होगा और नया नियंत्रण जोड़ना होगा।

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

foreach(Control c in Controls)
{
  ISaveable s = c as ISaveable;

  if( s != null )
      s.SaveToBusinessObject(myBusinessObject);
}

इंटरफेस के लिए असत्य लाभ का लाभ यह है कि आप संशोधनों का स्थानीयकरण करते हैं। एक बार परिभाषित करने के बाद, आप शायद ही कभी किसी एप्लिकेशन के समग्र प्रवाह को बदलेंगे, लेकिन आप अक्सर विस्तार-स्तर पर बदलाव करेंगे। जब आप विशिष्ट वस्तुओं में विवरण रखते हैं, तो ProcessA में बदलाव से ProcessB में परिवर्तन प्रभावित नहीं होगा। (बेस कक्षाएं भी आपको यह लाभ देती हैं।)

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

— ऑस्टिन सलोनन
स्रोत

4

एक बार अपनी कक्षा के लिए किसी व्यवहार को बाध्य करने के लिए आपको एक इंटरफ़ेस परिभाषित करना चाहिए।

एक पशु के व्यवहार में चलना, भोजन करना, दौड़ना आदि शामिल हो सकते हैं, इसलिए, आप उन्हें इंटरफेस के रूप में परिभाषित करते हैं।

एक अन्य व्यावहारिक उदाहरण ActionListener (या Runnable) इंटरफ़ेस है। जब आप किसी विशेष घटना पर नज़र रखने की आवश्यकता होती है तो आप उन्हें लागू करेंगे। इसलिए, आपको actionPerformed(Event e)अपनी कक्षा (या उपवर्ग) में विधि के लिए कार्यान्वयन प्रदान करना होगा । इसी तरह, रननेबल इंटरफ़ेस के लिए, आप public void run()विधि के लिए कार्यान्वयन प्रदान करते हैं ।

इसके अलावा, आपके पास इन इंटरफेस को किसी भी वर्ग द्वारा लागू किया जा सकता है।

एक और उदाहरण जहां इंटरफेस का उपयोग किया जाता है (जावा में) C ++ में दिए गए कई उत्तराधिकार को लागू करना है।

— समाधि-लेख
स्रोत

3

भगवान ने उन्हें इंटरफेस के संबंध में कई विरासत जैसी चीजें कहना बंद कर दें। आप एक वर्ग में एक अंतरफलक नहीं है । आप इसे लागू करें ।

— आंद्रेई रोनेया

4

मान लें कि आप झुंझलाहट चाहते हैं जो तब हो सकता है जब आप सोने की कोशिश करते हैं।

इंटरफेस से पहले मॉडल

class Mosquito {
    void flyAroundYourHead(){}
}

class Neighbour{
    void startScreaming(){}
}

class LampJustOutsideYourWindow(){
    void shineJustThroughYourWindow() {}
}

जैसा कि आप स्पष्ट रूप से देखते हैं कि कई 'चीजें' सोने की कोशिश करते समय कष्टप्रद हो सकती हैं।

इंटरफेस के बिना कक्षाओं का उपयोग

लेकिन जब इन वर्गों का उपयोग करने की बात आती है तो हमें समस्या होती है। उनमें कुछ भी सामान्य नहीं है। आपको प्रत्येक विधि को अलग से कॉल करना होगा।

class TestAnnoyingThings{
    void testAnnoyingThinks(Mosquito mosquito, Neighbour neighbour, LampJustOutsideYourWindow lamp){
         if(mosquito != null){
             mosquito.flyAroundYourHead();
         }
         if(neighbour!= null){
             neighbour.startScreaming();
         }
         if(lamp!= null){
             lamp.shineJustThroughYourWindow();
         }
    }
}

इंटरफेस के साथ मॉडल

इस संभावना को दूर करने के लिए हम एक पुनरावृत्ति पेश कर सकते हैं

interface Annoying{
   public void annoy();

}

और इसे कक्षाओं के अंदर लागू करें

class Mosquito implements Annoying {
    void flyAroundYourHead(){}

    void annoy(){
        flyAroundYourHead();
    }
}

class Neighbour implements Annoying{
    void startScreaming(){}

    void annoy(){
        startScreaming();
    }
}

class LampJustOutsideYourWindow implements Annoying{
    void shineJustThroughYourWindow() {}

    void annoy(){
        shineJustThroughYourWindow();
    }
}

इंटरफेस के साथ उपयोग

जिससे इन कक्षाओं का उपयोग बहुत आसान हो जाएगा

class TestAnnoyingThings{
    void testAnnoyingThinks(Annoying annoying){
        annoying.annoy();
    }
}

— मार्सिन सिजिमेक
स्रोत

ठीक है, लेकिन यह नहीं है Neighbourऔर LampJustOutsideYourWindowलागू करने के लिए भी है Annoying?

— स्टारडस्ट

हाँ, यह इंगित करने के लिए धन्यवाद। मैंने इस परिवर्तन के साथ एक संपादन किया है

— Marcin Szymczak

2

भुगतान करने के लिए सबसे आसान उदाहरण भुगतान प्रोसेसर की तरह है। (पेपैल, पीडीएस आदि)।

मान लें कि आप एक इंटरफ़ेस बनाते हैं IPaymentProcessor जिसमें ProcessACH और ProcessCreditCard विधियाँ हैं।

अब आप एक ठोस पेपैल कार्यान्वयन लागू कर सकते हैं। उन तरीकों को बनाते हुए पेपाल को विशिष्ट कार्य कहते हैं।

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

— प्रहार
स्रोत

2

यह आपको मॉक यूनिट टेस्टिंग (.Net) करने की भी अनुमति देता है। यदि आपकी कक्षा एक इंटरफ़ेस का उपयोग करती है, तो आप अपनी इकाई परीक्षण में ऑब्जेक्ट का आसानी से परीक्षण कर सकते हैं और तर्क का परीक्षण कर सकते हैं (वास्तव में डेटाबेस, या वेब सेवा, आदि को दबाए बिना)।

http://www.nmock.org/

— Jobo
स्रोत

2

यदि आप .NET फ्रेमवर्क असेंबलियों को ब्राउज़ करते हैं और किसी भी मानक ऑब्जेक्ट के लिए बेस कक्षाओं में ड्रिल करते हैं, तो आप कई इंटरफेस (ISomeName के रूप में नामित सदस्य) को नोटिस करेंगे।

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

जब वे किसी फ्रेमवर्क में स्पष्ट रूप से या अंतर्निहित रूप से भाग लेना चाहते हैं तो कक्षाएं इंटरफेस को लागू करती हैं। उदाहरण के लिए, आईडीसोपोलेट एक सामान्य इंटरफ़ेस है जो लोकप्रिय और उपयोगी डिस्पोज़ () विधि के लिए विधि हस्ताक्षर प्रदान करता है। एक फ्रेमवर्क में, जिसे आप या किसी अन्य डेवलपर को किसी वर्ग के बारे में जानना होगा, यदि वह IDisposable को लागू करता है, तो आप जानते हैं कि ((IDisposable) myObject) .Dispose () क्लीनअप उद्देश्यों के लिए कॉल करने के लिए उपलब्ध है।

CLASSIC EXAMPLE: बिना IDisposable इंटरफ़ेस को लागू किए, आप C # में "का उपयोग ()" कीवर्ड निर्माण का उपयोग नहीं कर सकते, क्योंकि इसके लिए आवश्यक है कि पैरामीटर के रूप में निर्दिष्ट किसी भी वस्तु को कथित रूप से IDisposable में डाला जा सकता है।

COMPLEX EXAMPLE: एक अधिक जटिल उदाहरण System.ComponentModel.Component क्लास होगा। यह वर्ग आईडीसोफाइल और IComponent दोनों को लागू करता है। अधिकांश, यदि नहीं, तो। .NET ऑब्जेक्ट्स, जिनके साथ एक विज़ुअल डिज़ाइनर जुड़ा हुआ है, IComponent को कार्यान्वित करता है ताकि IDE घटक के साथ इंटरैक्ट कर सकेगा।

निष्कर्ष: जैसा कि आप .NET फ्रेमवर्क से अधिक परिचित हो जाते हैं, पहली बात तो यह कि आप ऑब्जेक्ट ब्राउज़र में एक नया वर्ग या .NET रिफ्लेक्टर (फ्री) टूल ( http://www.red-gate.com ) के भीतर मुठभेड़ करेंगे । / उत्पादों / परावर्तक / ) यह देखना है कि यह किस वर्ग से विरासत में मिला है और यह भी कि इसे लागू करने वाले इंटरफेस को देखना है। .NET परावर्तक ऑब्जेक्ट ब्राउज़र से भी बेहतर है क्योंकि यह आपको व्युत्पन्न वर्गों को भी देखने देता है। यह आपको उन सभी वस्तुओं के बारे में जानने की अनुमति देता है जो एक विशेष वर्ग से प्राप्त होते हैं, जिससे संभवतः फ्रेमवर्क कार्यक्षमता के बारे में सीखना है जो आपको पता नहीं था। यह विशेष रूप से महत्वपूर्ण है जब .NET फ्रेमवर्क में अद्यतन या नए नामस्थान जोड़े जाते हैं।

— EnocNRoll - आनंदगोपाल परेडू
स्रोत

2

गौर कीजिए कि आप पहले व्यक्ति को निशानेबाजी का खेल बना रहे हैं। खिलाड़ी के पास चुनने के लिए कई बंदूकें हैं।

हमारे पास एक इंटरफ़ेस हो सकता है Gunजो एक फ़ंक्शन को परिभाषित करता है shoot()।

हमें Gunकक्षा के अलग-अलग उपवर्गों आदि की आवश्यकता है ShotGun Sniper।

ShotGun implements Gun{
    public void shoot(){
       \\shotgun implementation of shoot.
    } 
}

Sniper implements Gun{
    public void shoot(){
       \\sniper implementation of shoot.
    } 
}

निशानेबाज वर्ग

शूटर के हाथ में सभी हथियार हैं। Listइसे दर्शाने के लिए एक बनाएँ ।

List<Gun> listOfGuns = new ArrayList<Gun>();

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

public void switchGun(){
    //code to cycle through the guns from the list of guns.
    currentGun = //the next gun in the list.
}

हम उपरोक्त फ़ंक्शन का उपयोग करके वर्तमान गन सेट कर सकते हैं और बस shoot()फ़ंक्शन को कॉल कर सकते हैं, जब fire()कहा जाता है।

public void fire(){
    currentGun.shoot();
}

शूट फ़ंक्शन का व्यवहार Gunइंटरफ़ेस के विभिन्न कार्यान्वयन के अनुसार अलग-अलग होगा ।

निष्कर्ष

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

उदाहरण के लिए fire()से समारोह Shooterवर्ग बंदूकें (उम्मीद है Sniper, ShotGun) लागू करने के लिए shoot()कार्य करते हैं। इसलिए अगर हम बंदूक और आग को बंद कर दें।

shooter.switchGun();
shooter.fire();

हमने fire()फ़ंक्शन के व्यवहार को बदल दिया है ।

— श्रेणीबद्ध करनेवाला
स्रोत

1

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

— मैथ्यू Brubaker
स्रोत

1

आम तौर पर इंटरफेस का उपयोग तब किया जाता है जब आप एक व्यवहार को परिभाषित करना चाहते हैं जो ऑब्जेक्ट प्रदर्शित कर सकते हैं।

.NET की दुनिया में इसका एक अच्छा उदाहरण आईडीसोपोलेटरी इंटरफ़ेस है, जो किसी भी Microsoft कक्षाओं पर उपयोग किया जाता है जो सिस्टम संसाधनों का उपयोग करते हैं जिन्हें मैन्युअल रूप से जारी किया जाना चाहिए। इसके लिए आवश्यक है कि इसे लागू करने वाले वर्ग के पास डिस्पोज़ () पद्धति हो।

(डिस्पोज़ () विधि को VB.NET और C # के लिए भाषा निर्माण के द्वारा भी कहा जाता है , जो केवल IDisposables पर काम करता है )

ध्यान रखें कि आप यह जांच सकते हैं कि कोई ऑब्जेक्ट किसी विशिष्ट इंटरफ़ेस जैसे कि TypeOf ... Is(VB.NET), is(C #), instanceof(Java), आदि का उपयोग करके लागू करता है ...

— Powerlord
स्रोत

1

जैसा कि कई लोगों ने पहले से ही उत्तर दिया है, उन वर्गों के बीच कुछ व्यवहारों को लागू करने के लिए इंटरफेस का उपयोग किया जा सकता है जो उन व्यवहारों को उसी तरह लागू नहीं करेंगे। इसलिए एक इंटरफ़ेस लागू करके आप कह रहे हैं कि आपकी कक्षा में इंटरफ़ेस का व्यवहार है। IAnimal इंटरफ़ेस विशिष्ट इंटरफ़ेस नहीं होगा क्योंकि डॉग, कैट, बर्ड, आदि वर्ग जानवरों के प्रकार हैं, और संभवतः इसे विस्तारित करना चाहिए, जो विरासत का मामला है। इसके बजाय, एक इंटरफ़ेस इस मामले में जानवरों के व्यवहार की तरह अधिक होगा, जैसे कि IRunnable, IFlyable, ITrainable, आदि।

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

यह संभव है कि आप कभी भी इंटरफेस का उपयोग नहीं करेंगे, लेकिन यदि आप स्क्रैच से किसी प्रोजेक्ट को डिजाइन कर रहे हैं, विशेष रूप से किसी प्रकार का ढांचा, तो आप शायद उनसे परिचित होना चाहते हैं।

मैं आपको Coad, Mayfield और Kern द्वारा Java Design में इंटरफेस पर अध्याय पढ़ने की सलाह दूंगा। वे इसे औसत परिचयात्मक पाठ की तुलना में थोड़ा बेहतर बताते हैं। यदि आप जावा का उपयोग नहीं करते हैं, तो आप केवल अध्याय की शुरुआत पढ़ सकते हैं, जो कि मुख्य रूप से अवधारणाएं हैं।

— रयान थेम्स
स्रोत

1

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

यहाँ एक व्यापार बंद है, हमेशा की तरह: स्थिरता पर लचीलापन। कौन सा अधिक महत्वपूर्ण है? कोई जवाब नहीं है - यह परियोजना पर निर्भर करता है। लेकिन बस याद रखें कि हर सॉफ्टवेयर्स को बनाए रखना होगा ...

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

यह कहते हुए कि, आपको इंटरफ़ेस बनाने की आवश्यकता कब है?

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

और यह काम करता है: ओ)

एक अपवाद: जब मैं वस्तुओं का मजाक उड़ाता हूं, तो इंटरफ़ेस का उपयोग करना अधिक आसान होता है। इसलिए मैं अक्सर इसके लिए केवल इंटरफ़ेस बनाता हूं।

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

सादर, सिल्वैन

— सिल्वेन रॉड्रिग
स्रोत

1

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

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

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

इंटरफ़ेस से संबंधित कोडिंग के बारे में यह संबंधित प्रश्न भी देखें ।

— Fuhrmanator
स्रोत

1

इंटरफ़ेस का उपयोग करने के लिए बहुत सारे उद्देश्य हैं।

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

जैसे IUser, IOrder, IOrderItem

public interface IUser()
{

void AddUser(string name ,string fname);

}

// Same for IOrder and IOrderItem
//


public class  BusinessLayer: IUser, IOrder, IOrderItem

{    
    public void AddUser(string name ,string fname)
    {
        // Do stuffs here.
    }

    // All methods from all interfaces must be implemented.

}

यदि आप केवल एक उपयोगकर्ता जोड़ना चाहते हैं, तो इस तरह करें:

IUser user = new (IUser)BusinessLayer();

// It will load  all methods into memory which are declared in the IUser interface.

user.AddUser();

— Marc.2377
स्रोत