हमें गतिशील भाषाओं में इंटरफेस की आवश्यकता क्यों नहीं है?

Question

क्या यह गतिशील टाइपिंग के कारण है, हमें पाइथन में इंटरफ़ेस (जैसे जावा और सी #) की अवधारणा की आवश्यकता नहीं है?

Answer 1

interface एक कीवर्ड और आर्टिफैक्ट के रूप में जावा (और सी # इसे वहां से ले गया) द्वारा प्रस्तुत किया गया था ताकि यह वर्णन किया जा सके कि किसी ऑब्जेक्ट का अनुबंध क्या होना चाहिए।

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

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

@i = 1; 

आप प्रकार के i घोषित करने के लिए FixNum तुम सिर्फ इसका इस्तेमाल की जरूरत नहीं है। इंटरफेस के लिए वही जाता है, वे बस बहते हैं। व्यापार बंद है, आप उस पर स्थिर जांच नहीं कर सकते हैं और विफलताओं केवल रनटाइम पर दिखाए जाते हैं।

दूसरी ओर Structural type (या स्थैतिक बतख प्रकार जैसा कि मैं इसे कॉल करता हूं: पी) गो या स्कैला के रूप में भाषाओं द्वारा उपयोग किया जाता है, दोनों दुनिया के सर्वश्रेष्ठ प्रदान करता है।

_{1. देखें डैनियल Earwicker के बारे में CORBA interface कीवर्ड}

Answer 2

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

Answer 3

C# और जावा में टिप्पणी, इंटरफेस सभी सार तरीकों के साथ सिर्फ अमूर्त वर्ग हैं। वे वास्तव में पूर्ण विरासत एकाधिक विरासत का समर्थन किए बिना छद्म बहु-विरासत की अनुमति देने के लिए मौजूद हैं और अस्पष्टता एकाधिक विरासत बनाता है।

पायथन multiple inheritance का समर्थन करता है और यह निर्धारित करने का अपना तरीका है कि एकाधिक माता-पिता में कोई विधि मौजूद होने पर कौन सी माता-पिता की विधि को कॉल किया जाना चाहिए।

Answer 4

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

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

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

Answer 5

हम की आवश्यकता नहीं है, लेकिन हम का समर्थन करते हैं। Zope Interfaces देखें (जो ज़ोप के बाहर हो और उपयोग किया जा सकता है)।

Answer 6

गतिशील भाषाओं बतख टाइप कर रहे हैं

यह एक बतख की तरह चलता है और एक बतख की तरह नीम हकीमों, तो यह, एक बतख

http://en.wikipedia.org/wiki/Duck_typing

दूसरे शब्दों में होना चाहिए आप तो हटाएं() विधि को suport करने के लिए किसी ऑब्जेक्ट से बाहर निकलें, आप केवल

obj.Delete() 

का उपयोग कर सकते हैं

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

इंटरफेस के बिना आप स्थिर भाषाओं में ऐसा ही कुछ कर सकते हैं:

void Save(MyBaseClass item) 
{ 
    if (item.HasChanges) 
     item.Save() 
} 

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

public interface ISavable 
{ 
    bool HasChanges {get;set;} 
    void Save(); 
} 

void Save(ISavable item) 
{ 
    if (item.HasChanges) 
     item.Save() 
} 

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

void Save(object item) 
{ 
    if (item.HasChanges) 
     item.Save() 
} 

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

Answer 7

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

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

Answer 8

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

Answer 9

पर्ल भूमिकाओं (या लक्षण), यह जावा पर्ल की भूमिका निभाने के विपरीत इंटरफेस की तुलना में अधिक है कि हम एक कार्यान्वयन के बारे में अधिक पर्ल भूमिकाओं

• http://en.wikipedia.org/wiki/Perl_6#Roles
• http://use.perl.org/~Ovid/journal/38649

के लिए इन लिंक की जाँच हो सकता है है