इंटरफ़ेस-आधारित प्रोग्रामिंग: Difference between revisions
No edit summary |
No edit summary |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 8: | Line 8: | ||
== इंटरफेस आधारित प्रोग्रामिंग में सॉफ्टवेयर का विकास == | == इंटरफेस आधारित प्रोग्रामिंग में सॉफ्टवेयर का विकास == | ||
विभिन्न | विभिन्न समूहों को सहयोग करने की के लिए [[इंटरफ़ेस (कंप्यूटिंग)]] का उपयोग यह प्रश्न उत्पन्न करता है कि इंटरफ़ेस-आधारित प्रोग्रामिंग में इंटरफ़ेस परिवर्तन कैसे होते हैं। समस्या यह है कि यदि कोई इंटरफ़ेस परिवर्तित कर दिया गया है। उदा एक नई विधि जोड़कर, इंटरफ़ेस को प्रयुक्त करने के लिए लिखा गया पुराना कोड अब संकलित नहीं होगा और गतिशील रूप से लोड या लिंक किए गए प्लगइन्स के स्थितियों में या तो लोड या लिंक करने में विफल हो जाएगा या रनटाइम पर क्रैश हो जाएगा। इस समस्या के समाधान के लिए दो मूलभूत दृष्टिकोण होते हैं: | ||
# अतिरिक्त कार्यक्षमता के साथ नया इंटरफ़ेस विकसित किया जा सकता है। जो पुराने इंटरफ़ेस से प्राप्त हो सकता है। | # अतिरिक्त कार्यक्षमता के साथ नया इंटरफ़ेस विकसित किया जा सकता है। जो पुराने इंटरफ़ेस से प्राप्त हो सकता है। | ||
# एक सॉफ़्टवेयर संस्करण नीति जैसे कि [http://semver.org सिमेंटिक संस्करण 2.0] इंटरफ़ेस कार्यान्वयनकर्ताओं को सूचित किया जा सकता है। जिससे प्लेटफ़ॉर्म के भविष्य के प्रमुख संस्करणों में आगे-असंगत या यहां तक कि पिछड़े-असंगत परिवर्तनों की | # एक सॉफ़्टवेयर संस्करण नीति जैसे कि [http://semver.org सिमेंटिक संस्करण 2.0] इंटरफ़ेस कार्यान्वयनकर्ताओं को सूचित किया जा सकता है। जिससे प्लेटफ़ॉर्म के भविष्य के प्रमुख संस्करणों में आगे-असंगत या यहां तक कि पिछड़े-असंगत परिवर्तनों की स्वीकृति दी जा सके। | ||
इन दोनों उपायों का प्रयोग जावा प्लेटफॉर्म में किया गया है। | इन दोनों उपायों का प्रयोग जावा प्लेटफॉर्म में किया गया है। | ||
== अनुबंध द्वारा डिजाइन == | == अनुबंध द्वारा डिजाइन == | ||
इंटरफ़ेस के प्रकाशक सामान्यतः प्रण करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को नहीं | इंटरफ़ेस के प्रकाशक सामान्यतः यह प्रण करते हैं कि वे सॉफ़्टवेयर के नए छोटे संस्करणों में इंटरफ़ेस को परिवर्ति नहीं करेंगे और कार्यान्वयनकर्ता, इंटरफ़ेस को प्रयुक्त करके यह प्रदर्शित करता है कि उन्होंने बिना किसी विचलन के इंटरफ़ेस के कम से कम आवश्यक भागों को प्रयुक्त किया है। एक इंटरफ़ेस इसलिए एक "संविदात्मक समझौते" के रूप में एक प्रदाता और इंटरफ़ेस के उपभोक्ता के बीच देखा जा सकता है। यदि इस अनुबंध को सॉफ़्टवेयर विनिर्देश के रूप में अधिक औपचारिक रूप से प्रलेखित किया जाता है। जिससे यह अनुबंध द्वारा प्रारूप का एक उदाहरण है। चूँकि अनुबंध द्वारा प्रारूप सभी घटकों के लिए इंटरफेस के उपयोग को अनिवार्य नहीं करता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
| Line 28: | Line 28: | ||
* [http://www.rhyous.com/2011/10/18/architecting-a-large-application-with-interface-based-architecture/ Architecting a large application with interface-based architecture], rhyous.com, 18 October 2011 | * [http://www.rhyous.com/2011/10/18/architecting-a-large-application-with-interface-based-architecture/ Architecting a large application with interface-based architecture], rhyous.com, 18 October 2011 | ||
* [http://msdn.microsoft.com/en-us/library/aa260635%28v=vs.60%29.aspx Understanding Interface-based Programming], [[Microsoft Developers Network]], accessed 16 September 2016 | * [http://msdn.microsoft.com/en-us/library/aa260635%28v=vs.60%29.aspx Understanding Interface-based Programming], [[Microsoft Developers Network]], accessed 16 September 2016 | ||
[[Category:Created On 13/05/2023]] | [[Category:Created On 13/05/2023]] | ||
[[Category:Machine Translated Page]] | |||
[[Category:वास्तुकला पैटर्न (कंप्यूटर विज्ञान)]] | |||
Latest revision as of 08:04, 13 June 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
