इंटरफ़ेस-आधारित प्रोग्रामिंग: Difference between revisions
No edit summary |
No edit summary |
||
| Line 16: | Line 16: | ||
== अनुबंध द्वारा डिजाइन == | == अनुबंध द्वारा डिजाइन == | ||
इंटरफ़ेस के प्रकाशक सामान्यतः | इंटरफ़ेस के प्रकाशक सामान्यतः प्रण करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को नहीं और कार्यान्वयनकर्ता, इंटरफ़ेस को प्रयुक्त करके यह है कि उन्होंने बिना किसी विचलन के इंटरफ़ेस के कम से कम आवश्यक भागों को प्रयुक्त किया है। इंटरफ़ेस इसलिए एक संविदात्मक समझौते के रूप में देखा जा सकता है। यदि इस अनुबंध को सॉफ़्टवेयर विनिर्देश के रूप में अधिक औपचारिक रूप से प्रलेखित किया जाता है, तो यह अनुबंध द्वारा डिज़ाइन का एक उदाहरण है। चूँकि, अनुबंध द्वारा डिज़ाइन सभी घटकों के लिए इंटरफेस के उपयोग को अनिवार्य नहीं करता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[माइक्रोसर्विसेज]] | * [[माइक्रोसर्विसेज]] | ||
* [[अभिनेता मॉडल]] | * [[अभिनेता मॉडल|एक्टर मॉडल]] | ||
* [[CORBA]], ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के लिए एक पुरानी घटक-आधारित प्रणाली | * [[CORBA|कोबरा]], ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के लिए एक पुरानी घटक-आधारित प्रणाली है। जो अब विभिन्न कारणों से संभवतः ही कभी उपयोग की जाती है। | ||
== संदर्भ == | == संदर्भ == | ||
Revision as of 13:04, 19 May 2023
इंटरफ़ेस-आधारित प्रोग्रामिंग, जिसे इंटरफ़ेस-आधारित आर्किटेक्चर के रूप में भी जाना जाता है, ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग भाषा में सॉफ़्टवेयर घटक स्तर पर मॉड्यूलर प्रोग्रामिंग को प्रयुक्त करने के लिए आर्चीटेक्टरल पैटर्न का प्रयोग होता है| जिसमें मॉड्यूल प्रणाली नहीं होती है। ऐसी भाषा का एक उदाहरण जावा (प्रोग्रामिंग भाषा) है| जो (2015 तक) घटकों के स्तर पर मॉड्यूल प्रणाली नहीं है। जावा में पैकेज प्रणाली होती है| किन्तु जावा सॉफ्टवेयर घटकों में सामान्यतः कई जावा पैकेज होते हैं और किसी भी स्थिति में इंटरफ़ेस प्रोग्रामिंग एकमात्र जावा पैकेज का उपयोग करने पर लाभ प्रदान कर सकता है| तथापि एक घटक में एकमात्र जावा पैकेज हो।
इंटरफ़ेस-आधारित प्रोग्रामिंग एप्लिकेशन को घटकों के संग्रह के रूप में परिभाषित करती है| जिसमें घटकों के बीच अप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) कॉल एकमात्र सार इंटरफेस के माध्यम से किया जा सकता है| ठोस वर्ग नहीं किया जा सकता है। फैक्टरी पैटर्न जैसी विधियों का उपयोग करके कक्षाओं के उदाहरण सामान्यतः अन्य इंटरफेस के माध्यम से प्राप्त किए जाएंगे।
यह प्रमाणित किया जाता है कि यह एप्लिकेशन की मॉड्यूलरिटी और इसकी देखभाल क्षमता को बढ़ाता है। चूँकि कुछ सावधानी की जाती है। इंटरफेस के माध्यम से संचार करने वाले इच्छानुसार घटकों में किसी एप्लिकेशन को विभाजित करना स्वयं में कम युग्मन (कंप्यूटर प्रोग्रामिंग) या उच्च सामंजस्य (कंप्यूटर विज्ञान) की गारंटी नहीं प्रदान करता है। दो अन्य विशेषताएँ जिन्हें सामान्यतः देखभाल के लिए महत्वपूर्ण माना जाता है।
तीसरे पक्ष के होने पर इंटरफ़ेस-आधारित आर्किटेक्चर का उपयोग किया जा सकता है। यह वास्तव में एक ही संगठन के अंदर टीमों को अलग करें किसी स्थापित प्रणाली के लिए अतिरिक्त घटक या प्लगइन विकसित करें। एक्लिप्स आईडीई का कोडबेस इंटरफ़ेस-आधारित प्रोग्रामिंग का एक उदाहरण है। ग्रहण प्लगइन विक्रेताओं को एकमात्र ऐसे घटकों को विकसित करना होगा। जो मूल अनुप्रयोग विक्रेता, एक्लिप्स फाउंडेशन द्वारा निर्दिष्ट इंटरफ़ेस को संतुष्ट करते हैं। दरअसल, ग्रहण आईडीई, जावा डेवलपमेंट टूल्स जैसे मूल घटक भी स्वयं प्लगइन्स हैं। यह कुछ सीमा तक एक मूविंग दूरभाष निर्माता द्वारा मोबाइल चार्जर इंटरफ़ेस (पिन व्यवस्था, अपेक्षित प्रत्यक्ष धाराएँ वोल्टेज, आदि) निर्दिष्ट करने और निर्माता और तीसरे पक्ष दोनों स्वयं के मोबाइल फोन चार्जर बनाने के समान है। जो इस मानक इंटरफ़ेस विनिर्देश का अनुपालन करते हैं।
इंटरफेस आधारित प्रोग्रामिंग में सॉफ्टवेयर का विकास
विभिन्न टीमों को सहयोग करने की अनुमति देने के लिए इंटरफ़ेस (कंप्यूटिंग) का उपयोग यह प्रश्न उठाता है कि इंटरफ़ेस-आधारित प्रोग्रामिंग में इंटरफ़ेस परिवर्तन कैसे होते हैं। समस्या यह है कि यदि कोई इंटरफ़ेस बदल दिया गया है। उदा एक नई विधि जोड़कर, इंटरफ़ेस को प्रयुक्त करने के लिए लिखा गया पुराना कोड अब संकलित नहीं होगा और गतिशील रूप से लोड या लिंक किए गए प्लगइन्स के स्थितियों में या तो लोड या लिंक करने में विफल हो जाएगा या रनटाइम पर क्रैश हो जाएगा। इस समस्या से निपटने के लिए दो मूलभूत दृष्टिकोण हैं:
- अतिरिक्त कार्यक्षमता के साथ नया इंटरफ़ेस विकसित किया जा सकता है। जो पुराने इंटरफ़ेस से प्राप्त हो सकता है।
- एक सॉफ़्टवेयर संस्करण नीति जैसे कि सिमेंटिक संस्करण 2.0 इंटरफ़ेस कार्यान्वयनकर्ताओं को सूचित किया जा सकता है। जिससे प्लेटफ़ॉर्म के भविष्य के प्रमुख संस्करणों में आगे-असंगत या यहां तक कि पिछड़े-असंगत परिवर्तनों की अनुमति दी जा सके।
इन दोनों उपायों का प्रयोग जावा प्लेटफॉर्म में किया गया है।
अनुबंध द्वारा डिजाइन
इंटरफ़ेस के प्रकाशक सामान्यतः प्रण करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को नहीं और कार्यान्वयनकर्ता, इंटरफ़ेस को प्रयुक्त करके यह है कि उन्होंने बिना किसी विचलन के इंटरफ़ेस के कम से कम आवश्यक भागों को प्रयुक्त किया है। इंटरफ़ेस इसलिए एक संविदात्मक समझौते के रूप में देखा जा सकता है। यदि इस अनुबंध को सॉफ़्टवेयर विनिर्देश के रूप में अधिक औपचारिक रूप से प्रलेखित किया जाता है, तो यह अनुबंध द्वारा डिज़ाइन का एक उदाहरण है। चूँकि, अनुबंध द्वारा डिज़ाइन सभी घटकों के लिए इंटरफेस के उपयोग को अनिवार्य नहीं करता है।
यह भी देखें
- माइक्रोसर्विसेज
- एक्टर मॉडल
- कोबरा, ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के लिए एक पुरानी घटक-आधारित प्रणाली है। जो अब विभिन्न कारणों से संभवतः ही कभी उपयोग की जाती है।
संदर्भ
- 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
