क्या इंटरफेस और अमूर्त वर्गों के बीच कोई अंतर है जो केवल अमूर्त तरीके हैं?

Question

मान लें कि हमारे पास एक अमूर्त वर्ग है और इस वर्ग को केवल अमूर्त तरीके हैं। क्या यह अमूर्त वर्ग एक इंटरफ़ेस से अलग है जिसमें केवल एक ही विधियाँ हैं?

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

Comments

कौनसी भाषा?

— केविन क्लाइन

जहाँ तक मैं बता सकता हूँ, आपके प्रश्न का उत्तर दो बार डुप्लिकेट में दिया गया है : यहाँ और यहाँ । और ये दो उत्तर भाषा अज्ञेय हैं, C # के लिए कुछ भी विशिष्ट नहीं है

— gnat

@blank मैं आपके प्रश्न पर लागू डुप्लिकेट स्थिति से असहमत था इसलिए मैंने इसे फिर से खोल दिया। इसके अलावा, मैंने आपके प्रश्न को और स्पष्ट करने के लिए संपादित किया कि मुझे विश्वास है कि आप पूछ रहे हैं।

— maple_shaft

Answer 1

तकनीकी रूप से, अंतर वास्तव में महत्वपूर्ण नहीं हैं लेकिन, वैचारिक रूप से, वे पूरी तरह से अलग चीजें हैं और जो तकनीकी अंतर दूसरों का उल्लेख करते हैं।

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

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

लेकिन वे सभी अभी भी पशु हैं और कुछ सामान्य गुण हैं, जैसे कि वे जीवित हैं या मृत हैं।

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

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

Comments

+1, हालाँकि बिल्लियाँ साँप या छिपकली की तुलना में बहुत अधिक कष्टप्रद तरीके से बहती हैं।

— मैथ्यू फ्लिन

तकनीकी रूप से: सार विधियों को संरक्षित किया जा सकता है। इंटरफ़ेस के तरीके खिचड़ी भाषा।

— जैक कोर्ट्स

Answer 2

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

Comments

अधिकांश? आप किन लोगों को गिन रहे हैं? अधिकांश ओओपी भाषाएं मुझे पता है कि उनके पास इंटरफेस या अमूर्त कक्षाएं नहीं हैं। C ++ में केवल अमूर्त वर्ग हैं।

— केविन क्लाइन

@kevincline: शायद C #, Java और VB.NET।

— tdammers

@kevincline, मुझे लगता है कि दोनों में "कमी" है। IIRC, Ada में इंटरफ़ेस के लिए प्रेरणा यह थी कि एक, डिजाइनर एक सामान्य एकाधिक वंशानुक्रम सुविधा नहीं चाहते थे, लेकिन इंटरफ़ेस के विशेष मामले को प्रदान नहीं किए जाने के लिए बहुत महत्वपूर्ण माना गया था।

— एपीग्रामग्राम

@ दोस्त: LOL। यही कारण है कि था एक मजाक, है ना?

— केविन क्लाइन

Answer 3

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

PHP और C # जैसी भाषाओं में, इंटरफेस समान बहुरूपता प्राप्त करने का एक साधन प्रदान करते हैं, हालांकि मैं इसे "विरासत" कहना पसंद नहीं करता हूं क्योंकि एक सार वर्ग को विरासत में देने और एक इंटरफ़ेस को लागू करने के बीच एक वैचारिक अंतर है। इंटरफेस संघर्ष की समस्या को दूर करते हैं, क्योंकि वे स्वयं कोई कार्यान्वयन प्रदान नहीं करते हैं।

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

मुख्य वैचारिक अंतर यह है कि जब एक वर्ग दूसरे वर्ग (अमूर्त या नहीं) को विरासत में लेता है, तो "इज" का एक संबंध होता है, इसलिए एक Carएक Vehicleऔर Dogएक है Animal। एक इंटरफेस के साथ, यह वही है जो वस्तु मायने रखती है। इसलिए दोनों Carऔर Dogकर सकते हैं Move()और उपभोक्ता इसे जानता है क्योंकि वे लागू करते हैं Movable, लेकिन एक कार निश्चित रूप से एक Dogया एक नहीं है Animal। और चाल कार्यान्वयन अलग होगा (पहियों बनाम पैर), लेकिन खपत कोड की देखभाल नहीं करनी चाहिए। कार्यान्वयन के बजाय, सभी उपभोग कोड के बारे में हैं।

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

Comments

इंटरफ़ेस एक प्रकार है और साथ ही, आप एक IAnimal हो सकते हैं जो दोनों हैं Dogऔर Cat हैं ।

— एमी ब्लैंकेनशिप

आप कर सकते हैं, लेकिन मेरी राय में, इंटरफेस व्यवहार के बारे में हैं जो बाहरी दुनिया के संपर्क में हैं, और वस्तुओं के बारे में इतना नहीं है। इनहेरिटेंस का तात्पर्य है कि कुछ एक प्रकार का कुछ और है (कैट एक पशु है)। एक इंटरफ़ेस बस कहता है कि वस्तु क्या कर सकती है। इसलिए मुझे यह कहना पसंद है कि एक इंटरफ़ेस से "विरासत" के बजाय कुछ "लागू" होता है, जो कि जिस तरह से .Net लोगों ने मेरे साथ काम किया है, वह कहेगा (मुझे लगता है क्योंकि सिंटैक्स विरासत और कार्यान्वयन के लिए समान है)।

— इवान पिंटर

Answer 4

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

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

Comments

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

— इवान पिंटर

हां, मैं ऐसा कुछ सोच रहा था, लेकिन इसके साथ कोई अनुभव नहीं है, इसलिए न्याय नहीं कर सका। इनपुट के लिए धन्यवाद।

— थॉमस

सिर्फ एक नोट। कुछ भाषाओं में, व्युत्पन्न कक्षाओं में निजी आभासी तरीकों को ओवरराइड किया जा सकता है।

— जोहान बोले

Answer 5

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

Answer 6

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

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

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

Comments

अमूर्त तरीके किसी भी कार्यान्वयन के बिना परिभाषित नहीं हैं, और कार्यान्वयन को विरासत की कक्षाओं में छोड़ देते हैं?

— इवान पिंटर

हाँ आपका अधिकार तो मुझे लगता है कि इसके सिर्फ चर, निर्माणकर्ता और स्थिर और निजी तरीके अगर आप गिनती करते हैं

— tgkprog

@Pinetree, अधिकतर समय आप अपने एब्सट्रैक्ट क्लासेस में कम से कम "वास्तविक" कोड चाहते हैं (कम से कम मैं जिस भाषा का उपयोग करता हूं, जिसमें एब्सट्रैक्ट क्लासेस के लिए कोई विशेष निर्माण नहीं है)।

— एमी ब्लैंकेनशिप

@AmyBlankenship हाँ, ज्यादातर अमूर्त वर्गों में "वास्तविक" कोड होता है (यही वे वहां मौजूद हैं)। लेकिन मैं अमूर्त तरीकों की बात कर रहा था, एक विशुद्ध रूप से अमूर्त वर्ग के संदर्भ में जो C ++ जैसी भाषा में एक इंटरफ़ेस के रूप में कार्य करता है, जिसमें इंटरफेस नहीं है।

— इवान पिंटर