इंटरफ़ेस-आधारित प्रोग्रामिंग: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
<!-- IMPORTANT: need reliable source that says that this is specifically about OOP. If not, and if a suitable OOP-specific name cannot be located, this article should probably be merged into [[component-based software engineering]], which is the same thing but not specific to OOP. --> | <!-- IMPORTANT: need reliable source that says that this is specifically about OOP. If not, and if a suitable OOP-specific name cannot be located, this article should probably be merged into [[component-based software engineering]], which is the same thing but not specific to OOP. --> | ||
इंटरफ़ेस-आधारित प्रोग्रामिंग | '''इंटरफ़ेस-आधारित प्रोग्रामिंग''' जिसे '''इंटरफ़ेस-आधारित आर्किटेक्चर''' के रूप में भी जाना जाता है|[[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] भाषा में सॉफ़्टवेयर घटक स्तर पर [[मॉड्यूलर प्रोग्रामिंग]] को प्रयुक्त करने के लिए[[ वास्तु पैटर्न ]]होता है| जिसमें मॉड्यूल प्रणाली नहीं होती है। ऐसी भाषा का एक उदाहरण [[जावा (प्रोग्रामिंग भाषा)]] है| जो (2015 तक) घटकों के स्तर पर मॉड्यूल प्रणाली नहीं है। जावा में पैकेज प्रणाली है| लेकिन जावा सॉफ्टवेयर घटकों में सामान्यतः कई [[जावा पैकेज]] होते हैं{{spaced ndash}} और किसी भी स्थिति में इंटरफ़ेस प्रोग्रामिंग एकमात्र जावा पैकेज का उपयोग करने पर लाभ प्रदान कर सकता है| तथापि एक घटक में एकमात्र जावा पैकेज हो। | ||
इंटरफ़ेस-आधारित प्रोग्रामिंग एप्लिकेशन को घटकों के संग्रह के रूप में परिभाषित करती है, जिसमें घटकों के बीच [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] (एपीआई) कॉल | इंटरफ़ेस-आधारित प्रोग्रामिंग एप्लिकेशन को घटकों के संग्रह के रूप में परिभाषित करती है, जिसमें घटकों के बीच [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] (एपीआई) कॉल एकमात्र सार इंटरफेस के माध्यम से किया जा सकता है, ठोस वर्ग नहीं। [[ फैक्टरी पैटर्न ]] जैसी तकनीकों का उपयोग करके कक्षाओं के उदाहरण आम तौर पर अन्य इंटरफेस के माध्यम से प्राप्त किए जाएंगे। | ||
यह दावा किया जाता है कि यह एप्लिकेशन की मॉड्यूलरिटी को बढ़ाता है और इसलिए इसकी रखरखाव क्षमता। हालाँकि, कुछ सावधानी बरती जाती है{{spaced ndash}} इंटरफेस के माध्यम से संचार करने वाले मनमाने घटकों में किसी एप्लिकेशन को विभाजित करना अपने आप में कम [[युग्मन (कंप्यूटर प्रोग्रामिंग)]] या उच्च [[सामंजस्य (कंप्यूटर विज्ञान)]] की गारंटी नहीं देता है, दो अन्य विशेषताएँ जिन्हें | यह दावा किया जाता है कि यह एप्लिकेशन की मॉड्यूलरिटी को बढ़ाता है और इसलिए इसकी रखरखाव क्षमता। हालाँकि, कुछ सावधानी बरती जाती है{{spaced ndash}} इंटरफेस के माध्यम से संचार करने वाले मनमाने घटकों में किसी एप्लिकेशन को विभाजित करना अपने आप में कम [[युग्मन (कंप्यूटर प्रोग्रामिंग)]] या उच्च [[सामंजस्य (कंप्यूटर विज्ञान)]] की गारंटी नहीं देता है, दो अन्य विशेषताएँ जिन्हें सामान्यतः रखरखाव के लिए महत्वपूर्ण माना जाता है। | ||
तीसरे पक्ष के होने पर इंटरफ़ेस-आधारित आर्किटेक्चर का उपयोग किया जा सकता है{{spaced ndash}} या वास्तव में एक ही संगठन के भीतर टीमों को अलग करें{{spaced ndash}} किसी स्थापित | तीसरे पक्ष के होने पर इंटरफ़ेस-आधारित आर्किटेक्चर का उपयोग किया जा सकता है{{spaced ndash}} या वास्तव में एक ही संगठन के भीतर टीमों को अलग करें{{spaced ndash}} किसी स्थापित प्रणाली के लिए अतिरिक्त घटक या प्लगइन विकसित करें। एक्लिप्स आईडीई का कोडबेस इंटरफ़ेस-आधारित प्रोग्रामिंग का एक उदाहरण है। ग्रहण प्लगइन विक्रेताओं को एकमात्र ऐसे घटकों को विकसित करना होगा जो मूल अनुप्रयोग विक्रेता, एक्लिप्स फाउंडेशन द्वारा निर्दिष्ट इंटरफ़ेस को संतुष्ट करते हैं। दरअसल, [[ग्रहण आईडीई]], जावा डेवलपमेंट टूल्स जैसे मूल घटक भी स्वयं प्लगइन्स हैं। यह कुछ हद तक एक [[ चल दूरभाष ]] निर्माता द्वारा मोबाइल चार्जर इंटरफ़ेस (पिन व्यवस्था, अपेक्षित [[प्रत्यक्ष धाराएँ]] वोल्टेज, आदि) निर्दिष्ट करने और निर्माता और तीसरे पक्ष दोनों अपने स्वयं के मोबाइल फोन चार्जर बनाने के समान है जो इस मानक इंटरफ़ेस विनिर्देश का अनुपालन करते हैं। | ||
== इंटरफेस आधारित प्रोग्रामिंग में सॉफ्टवेयर का विकास == | == इंटरफेस आधारित प्रोग्रामिंग में सॉफ्टवेयर का विकास == | ||
अलग-अलग टीमों को सहयोग करने की अनुमति देने के लिए [[इंटरफ़ेस (कंप्यूटिंग)]] का उपयोग यह प्रश्न उठाता है कि इंटरफ़ेस-आधारित प्रोग्रामिंग में इंटरफ़ेस परिवर्तन कैसे होते हैं। समस्या यह है कि यदि कोई इंटरफ़ेस बदल दिया गया है, उदा। एक नई विधि जोड़कर, इंटरफ़ेस को | अलग-अलग टीमों को सहयोग करने की अनुमति देने के लिए [[इंटरफ़ेस (कंप्यूटिंग)]] का उपयोग यह प्रश्न उठाता है कि इंटरफ़ेस-आधारित प्रोग्रामिंग में इंटरफ़ेस परिवर्तन कैसे होते हैं। समस्या यह है कि यदि कोई इंटरफ़ेस बदल दिया गया है, उदा। एक नई विधि जोड़कर, इंटरफ़ेस को प्रयुक्त करने के लिए लिखा गया पुराना कोड अब संकलित नहीं होगा{{spaced ndash}} और गतिशील रूप से लोड या लिंक किए गए प्लगइन्स के स्थितियों में, या तो लोड या लिंक करने में विफल हो जाएगा, या रनटाइम पर क्रैश हो जाएगा। इस समस्या से निपटने के लिए दो बुनियादी दृष्टिकोण हैं: | ||
# अतिरिक्त कार्यक्षमता के साथ एक नया इंटरफ़ेस विकसित किया जा सकता है, जो पुराने इंटरफ़ेस से प्राप्त हो सकता है | # अतिरिक्त कार्यक्षमता के साथ एक नया इंटरफ़ेस विकसित किया जा सकता है, जो पुराने इंटरफ़ेस से प्राप्त हो सकता है | ||
| Line 17: | Line 17: | ||
== अनुबंध द्वारा डिजाइन == | == अनुबंध द्वारा डिजाइन == | ||
इंटरफ़ेस के प्रकाशक आम तौर पर वादा करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को नहीं बदलेंगे, और कार्यान्वयनकर्ता, इंटरफ़ेस को | इंटरफ़ेस के प्रकाशक आम तौर पर वादा करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को नहीं बदलेंगे, और कार्यान्वयनकर्ता, इंटरफ़ेस को प्रयुक्त करके, यह दर्शाता है कि उन्होंने बिना किसी विचलन के इंटरफ़ेस के कम से कम आवश्यक भागों को प्रयुक्त किया है। एक इंटरफ़ेस इसलिए एक संविदात्मक समझौते के रूप में देखा जा सकता है{{spaced ndash}} इंटरफ़ेस के प्रदाता और उपभोक्ता के बीच। यदि इस अनुबंध को सॉफ़्टवेयर विनिर्देश के रूप में अधिक औपचारिक रूप से प्रलेखित किया जाता है, तो यह अनुबंध द्वारा डिज़ाइन का एक उदाहरण है। हालाँकि, अनुबंध द्वारा डिज़ाइन सभी घटकों के लिए इंटरफेस के उपयोग को अनिवार्य नहीं करता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 12:35, 19 May 2023
इंटरफ़ेस-आधारित प्रोग्रामिंग जिसे इंटरफ़ेस-आधारित आर्किटेक्चर के रूप में भी जाना जाता है|ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग भाषा में सॉफ़्टवेयर घटक स्तर पर मॉड्यूलर प्रोग्रामिंग को प्रयुक्त करने के लिएवास्तु पैटर्न होता है| जिसमें मॉड्यूल प्रणाली नहीं होती है। ऐसी भाषा का एक उदाहरण जावा (प्रोग्रामिंग भाषा) है| जो (2015 तक) घटकों के स्तर पर मॉड्यूल प्रणाली नहीं है। जावा में पैकेज प्रणाली है| लेकिन जावा सॉफ्टवेयर घटकों में सामान्यतः कई जावा पैकेज होते हैं – और किसी भी स्थिति में इंटरफ़ेस प्रोग्रामिंग एकमात्र जावा पैकेज का उपयोग करने पर लाभ प्रदान कर सकता है| तथापि एक घटक में एकमात्र जावा पैकेज हो।
इंटरफ़ेस-आधारित प्रोग्रामिंग एप्लिकेशन को घटकों के संग्रह के रूप में परिभाषित करती है, जिसमें घटकों के बीच अप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) कॉल एकमात्र सार इंटरफेस के माध्यम से किया जा सकता है, ठोस वर्ग नहीं। फैक्टरी पैटर्न जैसी तकनीकों का उपयोग करके कक्षाओं के उदाहरण आम तौर पर अन्य इंटरफेस के माध्यम से प्राप्त किए जाएंगे।
यह दावा किया जाता है कि यह एप्लिकेशन की मॉड्यूलरिटी को बढ़ाता है और इसलिए इसकी रखरखाव क्षमता। हालाँकि, कुछ सावधानी बरती जाती है – इंटरफेस के माध्यम से संचार करने वाले मनमाने घटकों में किसी एप्लिकेशन को विभाजित करना अपने आप में कम युग्मन (कंप्यूटर प्रोग्रामिंग) या उच्च सामंजस्य (कंप्यूटर विज्ञान) की गारंटी नहीं देता है, दो अन्य विशेषताएँ जिन्हें सामान्यतः रखरखाव के लिए महत्वपूर्ण माना जाता है।
तीसरे पक्ष के होने पर इंटरफ़ेस-आधारित आर्किटेक्चर का उपयोग किया जा सकता है – या वास्तव में एक ही संगठन के भीतर टीमों को अलग करें – किसी स्थापित प्रणाली के लिए अतिरिक्त घटक या प्लगइन विकसित करें। एक्लिप्स आईडीई का कोडबेस इंटरफ़ेस-आधारित प्रोग्रामिंग का एक उदाहरण है। ग्रहण प्लगइन विक्रेताओं को एकमात्र ऐसे घटकों को विकसित करना होगा जो मूल अनुप्रयोग विक्रेता, एक्लिप्स फाउंडेशन द्वारा निर्दिष्ट इंटरफ़ेस को संतुष्ट करते हैं। दरअसल, ग्रहण आईडीई, जावा डेवलपमेंट टूल्स जैसे मूल घटक भी स्वयं प्लगइन्स हैं। यह कुछ हद तक एक चल दूरभाष निर्माता द्वारा मोबाइल चार्जर इंटरफ़ेस (पिन व्यवस्था, अपेक्षित प्रत्यक्ष धाराएँ वोल्टेज, आदि) निर्दिष्ट करने और निर्माता और तीसरे पक्ष दोनों अपने स्वयं के मोबाइल फोन चार्जर बनाने के समान है जो इस मानक इंटरफ़ेस विनिर्देश का अनुपालन करते हैं।
इंटरफेस आधारित प्रोग्रामिंग में सॉफ्टवेयर का विकास
अलग-अलग टीमों को सहयोग करने की अनुमति देने के लिए इंटरफ़ेस (कंप्यूटिंग) का उपयोग यह प्रश्न उठाता है कि इंटरफ़ेस-आधारित प्रोग्रामिंग में इंटरफ़ेस परिवर्तन कैसे होते हैं। समस्या यह है कि यदि कोई इंटरफ़ेस बदल दिया गया है, उदा। एक नई विधि जोड़कर, इंटरफ़ेस को प्रयुक्त करने के लिए लिखा गया पुराना कोड अब संकलित नहीं होगा – और गतिशील रूप से लोड या लिंक किए गए प्लगइन्स के स्थितियों में, या तो लोड या लिंक करने में विफल हो जाएगा, या रनटाइम पर क्रैश हो जाएगा। इस समस्या से निपटने के लिए दो बुनियादी दृष्टिकोण हैं:
- अतिरिक्त कार्यक्षमता के साथ एक नया इंटरफ़ेस विकसित किया जा सकता है, जो पुराने इंटरफ़ेस से प्राप्त हो सकता है
- एक सॉफ़्टवेयर संस्करण नीति जैसे कि सिमेंटिक संस्करण 2.0 इंटरफ़ेस कार्यान्वयनकर्ताओं को सूचित किया जा सकता है, ताकि प्लेटफ़ॉर्म के भविष्य के प्रमुख संस्करणों में आगे-असंगत, या यहां तक कि पिछड़े-असंगत, परिवर्तनों की अनुमति दी जा सके
इन दोनों तरीकों का इस्तेमाल जावा प्लेटफॉर्म में किया गया है।
अनुबंध द्वारा डिजाइन
इंटरफ़ेस के प्रकाशक आम तौर पर वादा करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को नहीं बदलेंगे, और कार्यान्वयनकर्ता, इंटरफ़ेस को प्रयुक्त करके, यह दर्शाता है कि उन्होंने बिना किसी विचलन के इंटरफ़ेस के कम से कम आवश्यक भागों को प्रयुक्त किया है। एक इंटरफ़ेस इसलिए एक संविदात्मक समझौते के रूप में देखा जा सकता है – इंटरफ़ेस के प्रदाता और उपभोक्ता के बीच। यदि इस अनुबंध को सॉफ़्टवेयर विनिर्देश के रूप में अधिक औपचारिक रूप से प्रलेखित किया जाता है, तो यह अनुबंध द्वारा डिज़ाइन का एक उदाहरण है। हालाँकि, अनुबंध द्वारा डिज़ाइन सभी घटकों के लिए इंटरफेस के उपयोग को अनिवार्य नहीं करता है।
यह भी देखें
- माइक्रोसर्विसेज
- अभिनेता मॉडल
- CORBA, ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के लिए एक पुरानी घटक-आधारित प्रणाली है जो अब विभिन्न कारणों से शायद ही कभी उपयोग की जाती है
संदर्भ
- C# Interface Based Development, c-sharpcorner.com
- Interface Based Development – The Unified Modeling Language (UML), devmentor.org
- Architecting a large application with interface-based architecture, rhyous.com, 18 October 2011
- Understanding Interface-based Programming, Microsoft Developers Network, accessed 16 September 2016
