एक इंटरफ़ेस और एक वर्ग के बीच अंतर क्या है, और मुझे एक इंटरफ़ेस का उपयोग क्यों करना चाहिए जब मैं कक्षा में सीधे तरीकों को लागू कर सकता हूं?


117

मुझे पता है कि यह एक बहुत ही बुनियादी सवाल है, लेकिन एक साक्षात्कारकर्ता ने मुझसे बहुत ही पेचीदा तरीके से पूछा और मैं असहाय था :(

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

मैं भी इंटरफ़ेस में एक बात समझ में नहीं आता है। उदाहरण के लिए, हम उपयोग करते हैं

conn.Dispose();अंत में ब्लॉक करें। लेकिन मैं यह नहीं देखता कि क्लास का मतलब IDisposableइंटरफ़ेस है या इनहेरिट कर SqlConnectionरहा है। मैं सोच रहा हूं कि कैसे मैं सिर्फ विधि नाम कह सकता हूं। इसके अलावा एक ही बात में, मुझे समझ नहीं आ रहा है कि डिस्पोज़ विधि कैसे काम करती है क्योंकि, हमें अपनी इंटरफ़ेस विधियों के लिए फ़ंक्शन को अपने स्वयं के कार्यान्वयन के साथ लागू करने की आवश्यकता है। तो इंटरफेसेस को अनुबंध के रूप में कैसे स्वीकार या नाम दिया जाता है? ये प्रश्न अब तक मेरे दिमाग में घूमते रहे और स्पष्ट रूप से मैंने कभी कोई अच्छा धागा नहीं देखा जो मेरे सवालों को इस तरह से समझाए कि मैं समझ सकूं।

एमएसडीएन हमेशा की तरह बहुत डरावना लग रहा है और कोई एकल लाइन स्पष्ट नहीं है ( फोल्क्स, कृपया बहाना जो उच्च स्तर के विकास में हैं, मुझे दृढ़ता से लगता है कि किसी भी कोड या लेख को देखने वाले के दिमाग में पहुंचना चाहिए, इसलिए जैसे कई अन्य कहते हैं, MSDN उपयोग का नहीं है )।

साक्षात्कारकर्ता ने कहा:

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

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


4
इंटरफेस वे हैं जिन्हें मैंने भी समझने के लिए संघर्ष किया है। अच्छा प्रश्न।
ब्रायन

4
एक ठोस कार्यान्वयन के बजाय एक सार अनुबंध के लिए प्रोग्रामिंग .... संक्षेप में, इसका मतलब है कि आप किसी भी वस्तु को प्रतिस्थापित कर सकते हैं जो एक इंटरफ़ेस की आवश्यकता होने पर एक इंटरफ़ेस को लागू करता है।
मिच गेहूं

7
SqlConnectionSystem.ComponentModel.Componentजो विरासत में मिला है IDisposable
ली

2
@ मिचव्हीट - इसका मतलब उदाहरण नहीं है, सवाल यह है कि कैसे SqlConnectionलागू होता है IDisposable
ली

ओह ली, जिसने मुझे धन्यवाद समझा। लेकिन मैं अभी भी नहीं देखता कि कैसे या कहाँ "डिस्पोज़" विधि कार्यक्षमता को परिभाषित किया गया है।
शिक्षार्थी

जवाबों:


92

जब आप कुछ ऐसा बनाना चाहते हैं तो इंटरफेस बहुत बढ़िया हैं:

using System;

namespace MyInterfaceExample
{
    public interface IMyLogInterface
    {
        //I want to have a specific method that I'll use in MyLogClass
        void WriteLog();       
    }

    public class MyClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyClass was Logged");
        }
    }

    public class MyOtherClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyOtherClass was Logged");
            Console.Write("And I Logged it different, than MyClass");
        }
    }

    public class MyLogClass
    {
        //I created a WriteLog method where I can pass as a parameter any object that implements IMyLogInterface.
        public static void WriteLog(IMyLogInterface myLogObject)
        {
            myLogObject.WriteLog(); //So I can use WriteLog here.
        }
    }

    public class MyMainClass
    {
        public void DoSomething()
        {
            MyClass aClass = new MyClass();
            MyOtherClass otherClass = new MyOtherClass();

            MyLogClass.WriteLog(aClass);//MyClass can log, and have his own implementation
            MyLogClass.WriteLog(otherClass); //As MyOtherClass also have his own implementation on how to log.
        }
    }
}

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


3
अरे, यह समझने के लिए मेरे लिए बहुत अच्छे घटक की तरह लग रहा है, मैं वास्तव में इसकी सराहना करता हूं, बहुत बहुत धन्यवाद :) :)
लर्नर

14
मेरा सवाल यह है कि अगर आप झटपट कर रहे हैं MyClassऔर MyOtherClassआप कॉल aClass.WriteLog()क्यों नहीं करेंगे तो उस अतिरिक्त कदम को क्यों जोड़ें। का कार्यान्वयन WriteLog()प्रत्येक वर्ग के लिए अलग-अलग रहेगा, लेकिन आपके पास पहले से ही वस्तु है इसलिए इसे हैंडलर कक्षा में क्यों दें?
ज़ैच एम।

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

2
@ZachM। यदि मैं सही हूं, तो उत्तर का मतलब है, वह कक्षाओं को तत्काल नहीं करेगा, लेकिन अन्य डेवलपर्स कक्षाओं को तुरंत भेज देंगे और इसे MyLogClass WriteLogविधि के पैरामीटर के रूप में पारित करेंगे । तो उसकी विधि किसी भी वस्तु को लागू कर सकती है जो लागू होती है IMyLogInterfaceयहाँ एक और दिलचस्प पोस्ट है।
शाइजुत

1
मेरा सवाल इंटरफ़ेस क्यों है ??? उपरोक्त परिदृश्य को सभी सार विधियों के साथ एक अमूर्त वर्ग द्वारा भी प्राप्त किया जा सकता है।
अभिजीत ओझा

52

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

public void DoSomething(Account account) {
  // Do awesome stuff here.
}

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

public void DoSomething(IAccount account) {
  // Do awesome stuff here.
}

यह समाधान एक कार्यान्वयन के लिए तय नहीं है, जिसका अर्थ है कि मैं इसे एक SuperSavingsAccount या एक ExclusiveAccount (दोनों IAccount इंटरफ़ेस को लागू करने वाला) पास कर सकता हूं और प्रत्येक कार्यान्वित खाते के लिए अलग-अलग व्यवहार प्राप्त कर सकता हूं।


45

इंटरफेस अनुबंध हैं जिन्हें कार्यान्वयनकर्ताओं को पालन करना चाहिए। सार वर्ग अनुबंधों और साझा कार्यान्वयनों की अनुमति देता है - ऐसा कुछ जो इंटरफेसेस नहीं हो सकता है। कक्षाएं कई इंटरफेस को लागू और विरासत में दे सकती हैं। कक्षाएं केवल एक अमूर्त वर्ग का विस्तार कर सकती हैं।

क्यों इंटरफ़ेस

  • आपके पास डिफ़ॉल्ट या साझा कोड कार्यान्वयन नहीं है
  • आप डेटा अनुबंध (वेब ​​सेवाएं, SOA) साझा करना चाहते हैं
  • आप प्रत्येक इंटरफ़ेस implementer के लिए अलग कार्यान्वयन (राशि IDbCommandहै SqlCommandऔर OracleCommandजो विशिष्ट तरीके से इंटरफ़ेस को लागू )
  • आप एकाधिक उत्तराधिकार का समर्थन करना चाहते हैं ।

क्यों सार


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

1
इंटरफेस और एसओए के बारे में एक व्यावहारिक उदाहरण के लिए, हम एक .NET असेंबली ( जैसे संविदा.शेयरिंग । डीएल) में अपने डब्ल्यूसीएफ इंटरफेस ( DataContracts) साझा करते हैं ताकि .NET क्लाइंट उपभोक्ता आसानी से उपयोग कर सकते हैं ( ऐड सर्विस संदर्भ के माध्यम से कोड उत्पन्न करने से बचते हुए , आदि) ) या साझा प्रकार के साथ जोड़ें सेवा संदर्भ का उपयोग करChannelFactory
SliverNinja - MSFT

यदि, मैं केवल सार विधियों के अंदर एक सार विधियों की घोषणा करूंगा, तो सार वर्ग इंटरफ़ेस के रूप में कार्य करेगा, फिर हमें इंटरफ़ेस की आवश्यकता क्यों है?
अभिजीत ओझा

25

यहां छवि विवरण दर्ज करें

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

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


यह समझ में आता है, लेकिन मैं अभी भी समझने के लिए संघर्ष कर रहा हूं, क्या आप पावरस्केट के लिए बस एक आधार वर्ग नहीं बना सकते हैं और यदि आवश्यक हो तो उन सभी चीजों को विरासत में मिला है। तकनीकी रूप से पावर सॉकेट्स को अन्य वर्गों के बारे में कोई जानकारी नहीं है।
अल्ताफ.हूसिन

मुझे लगता है क्योंकि C #
ह्यूग सीग्रेव्स

22

एक शब्द में - बहुरूपता के कारण !

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

  • निर्भरता इंजेक्शन में देखें और निश्चित रूप से डिजाइन पैटर्न - GOF द्वारा पुन: प्रयोज्य वस्तु उन्मुख सॉफ्टवेयर के तत्व पढ़ें ।

4

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


3
आप गतिशील प्रकार के साथ .net4 में ducktyping की तरह प्राप्त कर सकते हैं।
टोनी हॉपकिंसन

4

मेरा मानना ​​है कि इस सवाल को पूछने में पहले से ही कई खून बह गए थे, और कई रोबोट जैसी शर्तों को समझाकर इस मुद्दे को हल करने की कोशिश करते हैं, जिसे कोई भी सामान्य इंसान नहीं समझ सकता है।

सो फर्स्ट। यह जानने के लिए कि इंटरफ़ेस और क्यों सार आपको यह जानने की आवश्यकता है कि वे क्या हैं। फैक्ट्री क्लास लगाने के दौरान मैंने यह सीखा। आप इस लिंक पर एक अच्छा tuturial पाते हैं

अब मैं पहले से दिए गए लिंक के आधार पर खुदाई करता हूं।

आपके पास वाहन वर्ग है जो उपयोगकर्ता की आवश्यकता पर बदल सकता है (जैसे ट्रक , टैंक , हवाई जहाज आदि को जोड़ना और हमारे पास दिया गया)

public class clsBike:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Bike");
    }
    #endregion
}

तथा

public class clsCar:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Car");
    }
    #endregion
}

और दोनों में IChoice कॉन्ट्रैक्ट है जो केवल कहता है कि My Class के पास Buy Method होना चाहिए

public interface IChoice
{
    string Buy();
}

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

public abstract class Choice
{
    public abstract string Discount { get; }
    public abstract string Type { get; }
    public string Buy()
    {
       return "You buy" + Type + " with " + Discount;
}
public class clsBike: Choice
{
    public abstract string Discount { get { return "10% Discount Off"; } }
    public abstract string Type { get { return "Bike"; } }
}

public class clsCar:Choice
{
    public abstract string Discount { get { return " $15K Less"; } }
    public abstract string Type { get { return "Car"; } }
}

अब फ़ैक्टरी क्लास का उपयोग करके, आप उसी चीज़ को प्राप्त कर सकते हैं, लेकिन अमूर्त का उपयोग करके, आप बेस क्लास को Buy()विधि निष्पादित करते हैं ।

सारांश में: इंटरफ़ेस कॉन्ट्रैक्ट्स को इनहेरिट क्लास को लागू करने देते हैं जबकि एब्सट्रैक्ट क्लास कॉन्ट्रैक्ट्स को इनिशियलाइज़ कर सकते हैं (जो इनहेरर क्लास द्वारा ओवरराइड कर सकते हैं)


2

एक इंटरफेस के साथ आप निम्न कार्य कर सकते हैं:

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

2) इंटरफेस के बीच एक ही नाम के साथ कई तरीकों की अनुमति दें, क्योंकि हे, आपके पास कोई परस्पर विरोधी कार्यान्वयन नहीं है, बस एक हस्ताक्षर है।

3) आप अपने कार्यान्वयन के स्वतंत्र रूप से अपने इंटरफ़ेस को संस्करण और बंद कर सकते हैं, यह सुनिश्चित कर सकते हैं कि अनुबंध पूरा हो गया है।

4) आपका कोड समतलता के बजाय अमूर्तता पर भरोसा कर सकता है, स्मार्ट निर्भरता इंजेक्शन के लिए अनुमति देता है, जिसमें परीक्षण मोक्स आदि इंजेक्ट करना शामिल है।

और भी कई कारण हैं जो मुझे यकीन है, ये कुछ ही हैं।

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


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

2

@ User2211290 उत्तर के वास्तविक नमूने के रूप में:

दोनों Arrayऔर Listइंटरफेस है IList। नीचे हमारे पास एक string[]और एक है List<string>और IList का उपयोग करके दोनों को एक विधि से देखें :

string[] col1 = { "zero", "one", "two", "three", "four"};
List<string> col2 = new List<string>{ "zero", "one", "two", "three"};

//a methode that manipulates both of our collections with IList
static void CheckForDigit(IList collection, string digit)
{
    Console.Write(collection.Contains(digit));
    Console.Write("----");
    Console.WriteLine(collection.ToString()); //writes the type of collection
}

static void Main()
{
    CheckForDigit(col1, "one");   //True----System.String[]
    CheckForDigit(col2, "one");   //True----System.Collections.Generic.List`1[System.String]



//Another test:

    CheckForDigit(col1, "four");   //True----System.String[]
    CheckForDigit(col2, "four");   //false----System.Collections.Generic.List`1[System.String]
}

1

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

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


1

अमूर्त वर्ग और इंटरफ़ेस दोनों अनुबंध हैं।

एक अनुबंध का विचार है कि आप कुछ व्यवहार निर्दिष्ट करें। यदि आप कहते हैं कि आपने लागू किया है तो आप अनुबंध के लिए सहमत हो गए हैं।

इंटरफेस पर सार का विकल्प है।

अमूर्त वर्ग के किसी भी गैर सार वंशज अनुबंध को लागू करेगा।

बनाम

कोई भी वर्ग जो इंटरफ़ेस को लागू करता है, अनुबंध को लागू करेगा।

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


1

इंटरफेस वास्तविकता (ऑब्जेक्ट्स) के एब्स्ट्रैक्शन (क्लासेस) का एक एब्स्ट्रैक्शन (एक श्लोक) बनाना है।

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

इंटरफेस विनिर्देशों हैं:

  • इंटरफेस डिजाइन की कलाकृतियों को निर्दिष्ट करने के लिए डिजाइन समय की कलाकृतियां हैं क्योंकि यह अकेला और स्थिर है।

  • कक्षाएं वास्तविकता को मोबाइल संरचना को निर्दिष्ट करने के लिए समय कलाकृतियों को लागू कर रही हैं क्योंकि यह इंटरैक्ट करता है और चलता है।

इंटरफ़ेस क्या है?

जब आप एक बिल्ली का निरीक्षण करते हैं तो आप कह सकते हैं कि यह एक जानवर है जिसमें चार पंजे, एक सिर, एक ट्रंक, एक पूंछ और बाल हैं। आप देख सकते हैं कि वह चल, दौड़, खा और म्याऊ कर सकता है। और इसी तरह।

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

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

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

यह समझने के लिए कि हम पास्कल ऑब्जेक्ट कोडिंग का उल्लेख कर सकते हैं जहां आप एक इकाई में इंटरफ़ेस और कार्यान्वयन अनुभागों को परिभाषित करते हैं। इंटरफ़ेस में आप प्रकारों को परिभाषित करते हैं और कार्यान्वयन में आप प्रकार को लागू करते हैं:

unit UnitName;

interface

type
  TheClass = class
  public
    procedure TheMethod;
  end;

implementation

class procedure TheClass.TheMethod;
begin
end;

यहाँ, इंटरफ़ेस अनुभाग UML वर्ग डिज़ाइन से मेल खाता है, जबकि Interfaces प्रकार इस प्रकार अन्य चीजें हैं।

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

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

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

कक्षा क्या है?

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

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

जैसे, एक अमूर्त वर्ग किसी तरह संकलक के दृष्टिकोण से एक अंतरफलक के बराबर है।

अधिक जानकारी

प्रोटोकॉल (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)

सी # - इंटरफेस

सी # - कक्षाएं


1

आपको उड़ने वाली आपदाओं के बारे में बताता हूं।

उड़ान टोस्टर

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

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

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

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

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

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

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

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


0

अंतः कक्षा उपयोगकर्ता को अंतिम उपयोगकर्ता के लिए उपलब्ध विधियों को स्पष्ट करने की अनुमति देता है। वे बहुरूपता का एक अभिन्न अंग भी हैं।


अपने 1 कथन पर अच्छा कहा। लेकिन मुझे आपका दूसरा कथन समझ में आया, क्या आप कृपया एक वास्तविक समय उदाहरण के साथ विस्तृत कर सकते हैं?
शिक्षार्थी

0

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

जैसा कि आप जानते हैं कि इंटरफेस में कोई कोड नहीं हो सकता है, इसलिए डिस-वैंटेज समझने में काफी सरल है।

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

इसलिए बहुत सामान्य तौर पर आपको एब्स्ट्रैक्ट क्लास से लेकर इंटरफेस तक पसंद करना चाहिए, जब आपको क्लाइंट को कोई कंस्ट्रक्टर या कोई कोड देना होगा, जो आपकी क्लास को इनहेरिट / एक्सटेंड करेगा / करेगा।


-2

संबंधित संस्थाओं के लिए सार वर्ग का निर्धारण किया जाता है जहां असंबंधित संस्थाओं के लिए इंटरफेस का उपयोग किया जा सकता है।

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

नीचे जैसा दिखेगा

   Interface             
   ____|____
  |        |
Animal   Human



  Animal (Abstract class)
   __|___
  |      |
Tiger   Lion
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.