2010-05-03 9 views

उत्तर

10

इंटरफेस आपके प्रोग्राम को पहले और अधिक अनुमानित रूप से विफल होने का कारण बनता है जब एक उपclass अपने मूल वर्ग में कुछ अमूर्त विधि को लागू करने के लिए "भूल जाता है"।

पीएचपी की परंपरागत OOP में, आप एक रन-टाइम त्रुटि जारी करने के लिए निम्नलिखित की तरह कुछ पर भरोसा करने के लिए किया था:

class Base_interface { 
    function implement_me() { assert(false); } 
} 

class Child extends Base_interface { 
} 

एक इंटरफेस के साथ, आप मिल तत्काल प्रतिक्रिया जब अपने इंटरफेस के उपवर्गों में से एक नहीं है इस तरह के एक विधि को लागू करें, उस समय उपclass को इसके उपयोग के दौरान बाद में घोषित किया जाता है।

+0

PHP यदि कोई अनुपूरक विधि है तो कक्षा को लोड करने के तुरंत बाद PHP आपको एक त्रुटि देगा। – Reece45

+3

@stereofrog: आपने अभी अपने प्रश्न का उत्तर दिया है। जब आप एक इंटरफेस का उपयोग करते हैं और आप एक विधि को लागू करना भूल जाते हैं, तो संकलन के दौरान त्रुटि फेंक दी जाती है।यदि आप इसे ऊपर के रूप में करते हैं, तो आपको वास्तव में त्रुटि प्राप्त करने के लिए विधि को कॉल करना होगा। यह अंतर है। और हाँ, PHP में एक संकलन चरण है। इसे अभी भी इसे ऑपकोड पर संकलित करना है। सिर्फ इसलिए कि यह निष्पादन योग्य नहीं बनाता है इसका मतलब यह नहीं है कि इसमें संकलन चरण नहीं है। इसका अर्थ नहीं है। – ryeguy

+0

@ryeguy यह वास्तव में संकलित समय है जिसका मैं जिक्र कर रहा था, लेकिन यह पता चला है कि इस चरण के दौरान विधि-परिभाषित त्रुटियां नहीं उठाई गई हैं। वे उस बिंदु पर होते हैं जब दुभाषिया आपके उप-वर्ग घोषणा का सामना करता है। – meagar

0

यदि आप सटीक उसी हस्ताक्षर के साथ आवश्यक विधियों को नहीं जोड़ते हैं तो आपको त्रुटियां मिलती हैं।

0

इंटरफेस अक्सर इकाई परीक्षण (परीक्षण संचालित डिजाइन) के साथ उपयोग किया जाता है।

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

4

this link से लिया (यह सार अच्छी तरह से):

  • इंटरफेस आपके द्वारा निर्धारित/ अपनी कक्षाओं के लिए एक आम संरचना बनाने के लिए अनुमति देते हैं - वस्तुओं के लिए एक मानक निर्धारित ।
  • इंटरफेस एकल विरासत की समस्या का हल - वे आप कई स्रोतों से 'गुणों' इंजेक्षन करने देते हैं।
  • इंटरफेस एक लचीला बेस/रूट संरचना प्रदान करता है जिसे आप कक्षाओं के साथ प्राप्त नहीं करते हैं।
  • इंटरफेस बहुत अच्छे हैं जब आपके पास प्रोजेक्ट पर काम कर रहे एकाधिक कोडर हैं; आप प्रोग्राम्स के अनुसरण करने के लिए ढीली संरचना सेट कर सकते हैं और को विवरण के बारे में चिंता करने दें।
+0

दाएं। इंटरफेस के लिए _design_ लाभ हैं! अगर वे टाइपो और भूल गए तरीकों को पकड़ने का एक तरीका थे, तो वे किसी भी भाषा में बेकार के पास होंगे! – grossvogel

2

डेटाएप परत बनाने के दौरान मुझे व्यक्तिगत रूप से एक साफ समाधान इंटरफ़ेस करना पड़ता है जिसे एकाधिक डीबीएमएस का समर्थन करना होता है। प्रत्येक डीबीएमएस कार्यान्वयन को क्वेरी, FetchAssoc, FetchRow, NumRows, TransactionStart, TransactionCommit, TransactionRollback इत्यादि जैसे कार्यों के साथ वैश्विक डेटाएफ़-इंटरफ़ेस को कार्यान्वित करना होगा। इसलिए जब आप अपनी डेटा-एक्सेस पॉजिबिलिटी का विस्तार कर रहे हैं तो आपको एक सामान्य परिभाषित फ़ंक्शमा का उपयोग करने के लिए मजबूर होना चाहिए ताकि आप 'एप्लिकेशन कुछ बिंदु पर तोड़ नहीं देगा क्योंकि आपने फ़ंक्शन क्वेरी का पता लगाया है अब क्वेरी को execQuery नाम दिया जाना चाहिए।

Interfacing आप बड़ी तस्वीर :)

-4

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

जोड़ने के लिए भूल गए: असम्बद्ध डाउनवॉटिंग बेकार है। ; //

+3

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

+0

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

+1

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

0

इसे कमजोर टाइप किया जा सकता है, लेकिन विधियों के लिए संकेत संकेत दिया गया है: function myFunc(MyInterface $interface) इसके अलावा, इंटरफेस कोड परीक्षण और डीकॉप्लिंग के साथ मदद करते हैं।

0

फ़ंक्शन/विधि हस्ताक्षर में संकेत टाइप करने से आप कक्षा के पर्यावरण के साथ इंटरफेस के तरीके के बारे में अधिक नियंत्रण प्राप्त कर सकते हैं।

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

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

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

  • डिजाइन
  • प्रलेखन
  • वास्तविक प्रकार

पहले दो प्रकार सभी पर जाँच के किसी भी रूप की आवश्यकता नहीं है की जाँच:

1

प्रकार तीन अलग कार्य करते हैं। तो, अगर PHP कोई इंटरफेस की जांच करता है, तो वे अभी भी उन दो कारणों से उपयोगी होंगे।

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

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

अब तीसरे बिंदु पर: PHP वास्तव में टाइप इंटरफेस टाइप करें। सिर्फ इसलिए कि यह रनटाइम पर उन्हें टाइप करता है इसका मतलब यह नहीं है कि यह पर सभी पर टाइप न करें।

और, वास्तव में, यह और भी उन्हें रनटाइम पर, जाँच नहीं करता है यह लोड समय, जो क्रम से पहले होता है पर उन्हें जाँच करता है। और "टाइपटाइम पर टाइपिंग जांच नहीं होती है लेकिन इससे पहले" स्थिर प्रकार की जांच की बहुत परिभाषा है?

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