सॉफ्टवेयर फ्रेमवर्क: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{short description|Type of library that helps structure other software}} | {{short description|Type of library that helps structure other software}} | ||
{{Redirect|Framework (computer science)||Framework (disambiguation)}} | {{Redirect|Framework (computer science)||Framework (disambiguation)}} | ||
[[कंप्यूटर प्रोग्रामिंग]] में, | [[कंप्यूटर प्रोग्रामिंग]] में, सॉफ्टवेयर ढांचा [[अमूर्त (कंप्यूटर विज्ञान)]] है जिसमें सॉफ्टवेयर, सामान्य कार्यक्षमता प्रदान करते हुए, अतिरिक्त उपयोगकर्ता-लिखित कोड द्वारा चुनिंदा रूप से बदला जा सकता है, इस प्रकार एप्लिकेशन-विशिष्ट [[सॉफ़्टवेयर]] प्रदान करता है। यह अनुप्रयोगों को बनाने और तैनात करने का मानक तरीका प्रदान करता है और सार्वभौमिक, पुन: प्रयोज्य सॉफ़्टवेयर वातावरण (बहुविकल्पी) है जो सॉफ़्टवेयर अनुप्रयोगों, उत्पादों और समाधानों के विकास को सुविधाजनक बनाने के लिए बड़े [[सॉफ्टवेयर मंच]] के हिस्से के रूप में विशेष कार्यक्षमता प्रदान करता है। | ||
सॉफ्टवेयर फ्रेमवर्क में सपोर्ट प्रोग्राम, कंपाइलर, कोड लाइब्रेरी, टूलसेट और [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] | एप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआई) शामिल हो सकते हैं जो | सॉफ्टवेयर फ्रेमवर्क में सपोर्ट प्रोग्राम, कंपाइलर, कोड लाइब्रेरी, टूलसेट और [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] | एप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआई) शामिल हो सकते हैं जो [[सॉफ्टवेयर परियोजना]] या [[सॉफ्टवेयर सिस्टम]] के विकास को सक्षम करने के लिए सभी अलग-अलग [[सॉफ्टवेयर घटक]]ों को साथ लाते हैं। | ||
फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य [[पुस्तकालय (कम्प्यूटिंग)]] से अलग करती हैं: | फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य [[पुस्तकालय (कम्प्यूटिंग)]] से अलग करती हैं: | ||
* ''नियंत्रण का व्युत्क्रम'': | * ''नियंत्रण का व्युत्क्रम'': ढांचे में, पुस्तकालयों या मानक उपयोगकर्ता अनुप्रयोगों के विपरीत, समग्र कार्यक्रम का नियंत्रण प्रवाह कॉलर द्वारा निर्धारित नहीं किया जाता है, बल्कि रूपरेखा द्वारा निर्धारित किया जाता है।<ref>{{citation|url= http://www.riehle.org/computer-science/research/dissertation/diss-a4.pdf|first= Dirk|last= Riehle|title= Framework Design: A Role Modeling Approach|publisher= [[ETH Zurich|Swiss Federal Institute of Technology]]|year= 2000|postscript= <!--none-->}}</ref> यह आमतौर पर Template Method Pattern के साथ हासिल किया जाता है। | ||
* डिफ़ॉल्ट व्यवहार: यह | * डिफ़ॉल्ट व्यवहार: यह सार वर्ग में [[टेम्पलेट विधि पैटर्न]] के अपरिवर्तनीय तरीकों के साथ प्रदान किया जा सकता है जो ढांचे द्वारा प्रदान किया जाता है। | ||
* [[तानाना]]: | * [[तानाना]]: उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकता है - आमतौर पर चयनात्मक ओवरराइडिंग द्वारा - या प्रोग्रामर विशिष्ट कार्यक्षमता प्रदान करने के लिए विशेष उपयोगकर्ता कोड जोड़ सकते हैं। यह आमतौर पर उपवर्ग में हुक विधि द्वारा प्राप्त किया जाता है जो सुपरक्लास में टेम्पलेट विधि को ओवरराइड करता है। | ||
* खुला/बंद सिद्धांत | गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा लागू किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता ढांचे का विस्तार कर सकते हैं, लेकिन इसके कोड को संशोधित नहीं कर सकते। | * खुला/बंद सिद्धांत | गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा लागू किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता ढांचे का विस्तार कर सकते हैं, लेकिन इसके कोड को संशोधित नहीं कर सकते। | ||
== औचित्य == | == औचित्य == | ||
सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के बजाय डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।<ref>{{cite web |url=http://docforge.com/wiki/Framework |title=Framework |accessdate=15 December 2008 |work=DocForge |archive-date=7 October 2018 |archive-url=https://web.archive.org/web/20181007003315/http://www.docforge.com/wiki/Framework |url-status=dead }}</ref> उदाहरण के लिए, | सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के बजाय डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।<ref>{{cite web |url=http://docforge.com/wiki/Framework |title=Framework |accessdate=15 December 2008 |work=DocForge |archive-date=7 October 2018 |archive-url=https://web.archive.org/web/20181007003315/http://www.docforge.com/wiki/Framework |url-status=dead }}</ref> उदाहरण के लिए, बैंकिंग वेबसाइट विकसित करने के लिए [[वेब ढांचा]] का उपयोग करने वाली टीम अनुरोध प्रबंधन और [[राज्य प्रबंधन]] के यांत्रिकी के बजाय विशेष रूप से बैंकिंग के लिए कोड लिखने पर ध्यान केंद्रित कर सकती है। | ||
फ्रेमवर्क अक्सर कार्यक्रमों के आकार में वृद्धि करते हैं, | फ्रेमवर्क अक्सर कार्यक्रमों के आकार में वृद्धि करते हैं, घटना जिसे [[कोड ब्लोट]] कहा जाता है। ग्राहक-मांग-संचालित अनुप्रयोगों की जरूरतों के कारण, प्रतिस्पर्धी और पूरक ढांचे दोनों कभी-कभी उत्पाद में समाप्त हो जाते हैं। इसके अलावा, उनके एपीआई की जटिलता के कारण, ढांचे का उपयोग करने के लिए अतिरिक्त समय सीखने की आवश्यकता के कारण समग्र विकास समय में इच्छित कमी हासिल नहीं की जा सकती है; यह आलोचना स्पष्ट रूप से मान्य है जब विकास कर्मचारियों द्वारा पहली बार विशेष या नए ढांचे का सामना किया जाता है।{{citation needed|date=April 2011}} यदि इस तरह के ढाँचे का उपयोग बाद के कार्य कार्यों में नहीं किया जाता है, तो ढाँचे को सीखने में लगने वाला समय परियोजना के कर्मचारियों से परिचित उद्देश्य-लिखित कोड से अधिक खर्च हो सकता है; कई प्रोग्रामर आम जरूरतों के लिए उपयोगी [[बॉयलरप्लेट कोड]] की प्रतियां रखते हैं। | ||
हालाँकि, | हालाँकि, बार रूपरेखा सीख लेने के बाद, भविष्य की परियोजनाएँ तेज़ और आसानी से पूरी हो सकती हैं; ढांचे की अवधारणा आकार-फिट-सभी समाधान सेट बनाना है, और परिचितता के साथ, कोड उत्पादन तार्किक रूप से बढ़ना चाहिए। कोड के आकार के बारे में ऐसा कोई दावा नहीं किया गया है, जो अंततः आउटपुट उत्पाद के साथ बंडल किया गया है, न ही इसकी सापेक्ष दक्षता और संक्षिप्तता। किसी भी पुस्तकालय समाधान का उपयोग आवश्यक रूप से अतिरिक्त और अप्रयुक्त बाहरी संपत्तियों को खींचता है जब तक कि सॉफ़्टवेयर कंपाइलर-ऑब्जेक्ट लिंकर नहीं है जो तंग (छोटा, पूर्ण नियंत्रित और निर्दिष्ट) निष्पादन योग्य मॉड्यूल बनाता है। | ||
मुद्दा जारी है, लेकिन उद्योग के | मुद्दा जारी है, लेकिन उद्योग के दशक से अधिक का अनुभव{{citation needed|date=April 2011}} ने दिखाया है कि सबसे प्रभावी ढांचे वे होते हैं जो सामान्य उद्देश्यों के लिए तीसरे पक्ष द्वारा विकसित सामान्य आकार-फिट-सभी ढांचे का उपयोग करने के बजाय [[कोड रीफैक्टरिंग]]|उद्यम के सामान्य कोड को फिर से फैक्टरिंग से विकसित होते हैं। इसका उदाहरण यह होगा कि ऑफिस सूट जैसे एप्लिकेशन पैकेज में यूजर इंटरफेस कैसे सामान्य रूप, अनुभव और डेटा-साझाकरण विशेषताओं और विधियों के लिए बढ़ता है, बार अलग-अलग बंडल किए गए अनुप्रयोगों के रूप में, सूट में एकीकृत हो जाता है जो सख्त है। और छोटा; नया/विकसित सुइट ऐसा उत्पाद हो सकता है जो अभिन्न उपयोगिता पुस्तकालयों और उपयोगकर्ता इंटरफेस को साझा करता है। | ||
विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में | विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में महत्वपूर्ण मुद्दा उठाती है। ऐसा ढाँचा बनाना जो सुरुचिपूर्ण हो, बनाम वह जो केवल समस्या का समाधान करता हो, अभी भी विज्ञान के बजाय शिल्प है। सॉफ्टवेयर [[लालित्य]] का तात्पर्य स्पष्टता, संक्षिप्तता और थोड़ी बर्बादी (अतिरिक्त या बाहरी कार्यक्षमता, जिनमें से अधिकांश उपयोगकर्ता-परिभाषित है) है। उन रूपरेखाओं के लिए जो कोड उत्पन्न करते हैं, उदाहरण के लिए, लालित्य का मतलब कोड का निर्माण होता है जो उचित जानकार प्रोग्रामर (और जो आसानी से परिवर्तनीय है) के लिए स्वच्छ और समझने योग्य है, जो केवल सही कोड उत्पन्न करता है। लालित्य का मुद्दा यह है कि अपेक्षाकृत कुछ सॉफ्टवेयर फ्रेमवर्क समय की कसौटी पर खरे उतरे हैं: सबसे अच्छी रूपरेखाएँ अंतर्निहित तकनीक के रूप में विकसित होने में सक्षम हैं, जिस पर वे उन्नत बनाए गए थे। वहां भी, विकसित होने के बाद, ऐसे कई पैकेज अंतिम सॉफ्टवेयर को फुलाते हुए विरासत की क्षमताओं को बनाए रखेंगे क्योंकि अन्यथा बदले गए तरीकों को नए तरीकों के साथ समानांतर में रखा गया है। | ||
== उदाहरण == | == उदाहरण == | ||
| Line 41: | Line 41: | ||
== वास्तु == | == वास्तु == | ||
प्री के अनुसार,<ref>{{citation|title = Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design |author = Pree, W |journal = Proceedings of the 8th European Conference on Object-Oriented Programming |volume = 821 |pages = 150–162 |year = 1994 |publisher = [[Springer-Verlag]]|doi = 10.1007/BFb0052181 |citeseerx = 10.1.1.74.7935 |series = Lecture Notes in Computer Science |isbn = 978-3-540-58202-1 }}</ref> सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे | प्री के अनुसार,<ref>{{citation|title = Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design |author = Pree, W |journal = Proceedings of the 8th European Conference on Object-Oriented Programming |volume = 821 |pages = 150–162 |year = 1994 |publisher = [[Springer-Verlag]]|doi = 10.1007/BFb0052181 |citeseerx = 10.1.1.74.7935 |series = Lecture Notes in Computer Science |isbn = 978-3-540-58202-1 }}</ref> सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे सॉफ्टवेयर सिस्टम की समग्र वास्तुकला को परिभाषित करते हैं, अर्थात इसके मूल घटक और उनके बीच संबंध। ये एप्लिकेशन ढांचे के किसी भी तात्कालिकता में अपरिवर्तित (जमे हुए) रहते हैं। हॉट स्पॉट उन हिस्सों का प्रतिनिधित्व करते हैं जहां फ्रेमवर्क का उपयोग करने वाले प्रोग्रामर अपने स्वयं के प्रोजेक्ट के लिए विशिष्ट कार्यक्षमता जोड़ने के लिए अपना कोड जोड़ते हैं। | ||
वस्तु-उन्मुख प्रोग्रामिंग | वस्तु-उन्मुख वातावरण में, रूपरेखा में [[सार वर्ग]] और वर्ग (कंप्यूटर विज्ञान) # कंक्रीट वर्ग वर्ग (कंप्यूटर विज्ञान) होते हैं। इस तरह के ढांचे के [[उदाहरण (कंप्यूटर विज्ञान)]] में मौजूदा वर्ग की [[वस्तु रचना]] और [[उपवर्ग (कंप्यूटर विज्ञान)]] शामिल हैं।<ref>{{citation|last = Buschmann|first = F|year = 1996|title = Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester|publisher = [[John Wiley & Sons|Wiley]]|isbn = 978-0-471-95869-7}}</ref> | |||
टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को लागू किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को वेरिएंट या हुक विधियों के रूप में जाना जाता है। सुपरक्लास में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं जबकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं। | टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को लागू किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को वेरिएंट या हुक विधियों के रूप में जाना जाता है। सुपरक्लास में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं जबकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं। | ||
सॉफ़्टवेयर ढांचे के साथ | सॉफ़्टवेयर ढांचे के साथ ठोस सॉफ़्टवेयर सिस्टम विकसित करते समय, डेवलपर्स सिस्टम की विशिष्ट आवश्यकताओं और आवश्यकताओं के अनुसार हॉट स्पॉट का उपयोग करते हैं। सॉफ्टवेयर फ्रेमवर्क [[हॉलीवुड सिद्धांत]] पर निर्भर करता है: हमें कॉल न करें, हम आपको कॉल करेंगे।<ref>{{citation|last = Larman|first = C|year = 2001|title = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process|isbn = 978-0-13-092569-5|publisher = [[Prentice Hall]]|edition = 2nd}}</ref><ref>{{cite book|title=Design Patterns|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|publisher=Addison-Wesley|year=1994|isbn=0-201-63361-2|authorlink1=Erich Gamma|authorlink2=Richard Helm|authorlink3=Ralph Johnson (computer scientist)|authorlink4=John Vlissides|title-link=Design Patterns}}</ref> इसका अर्थ है कि उपयोगकर्ता-परिभाषित वर्ग (उदाहरण के लिए, नए उपवर्ग) पूर्वनिर्धारित रूपरेखा वर्गों से संदेश प्राप्त करते हैं। डेवलपर्स आमतौर पर सुपरक्लास (कंप्यूटर साइंस) [[सार विधि]]यों को लागू करके इसे संभालते हैं। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 19:23, 18 February 2023
कंप्यूटर प्रोग्रामिंग में, सॉफ्टवेयर ढांचा अमूर्त (कंप्यूटर विज्ञान) है जिसमें सॉफ्टवेयर, सामान्य कार्यक्षमता प्रदान करते हुए, अतिरिक्त उपयोगकर्ता-लिखित कोड द्वारा चुनिंदा रूप से बदला जा सकता है, इस प्रकार एप्लिकेशन-विशिष्ट सॉफ़्टवेयर प्रदान करता है। यह अनुप्रयोगों को बनाने और तैनात करने का मानक तरीका प्रदान करता है और सार्वभौमिक, पुन: प्रयोज्य सॉफ़्टवेयर वातावरण (बहुविकल्पी) है जो सॉफ़्टवेयर अनुप्रयोगों, उत्पादों और समाधानों के विकास को सुविधाजनक बनाने के लिए बड़े सॉफ्टवेयर मंच के हिस्से के रूप में विशेष कार्यक्षमता प्रदान करता है।
सॉफ्टवेयर फ्रेमवर्क में सपोर्ट प्रोग्राम, कंपाइलर, कोड लाइब्रेरी, टूलसेट और अप्लिकेशन प्रोग्रामिंग अंतरफलक | एप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआई) शामिल हो सकते हैं जो सॉफ्टवेयर परियोजना या सॉफ्टवेयर सिस्टम के विकास को सक्षम करने के लिए सभी अलग-अलग सॉफ्टवेयर घटकों को साथ लाते हैं।
फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य पुस्तकालय (कम्प्यूटिंग) से अलग करती हैं:
- नियंत्रण का व्युत्क्रम: ढांचे में, पुस्तकालयों या मानक उपयोगकर्ता अनुप्रयोगों के विपरीत, समग्र कार्यक्रम का नियंत्रण प्रवाह कॉलर द्वारा निर्धारित नहीं किया जाता है, बल्कि रूपरेखा द्वारा निर्धारित किया जाता है।[1] यह आमतौर पर Template Method Pattern के साथ हासिल किया जाता है।
- डिफ़ॉल्ट व्यवहार: यह सार वर्ग में टेम्पलेट विधि पैटर्न के अपरिवर्तनीय तरीकों के साथ प्रदान किया जा सकता है जो ढांचे द्वारा प्रदान किया जाता है।
- तानाना: उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकता है - आमतौर पर चयनात्मक ओवरराइडिंग द्वारा - या प्रोग्रामर विशिष्ट कार्यक्षमता प्रदान करने के लिए विशेष उपयोगकर्ता कोड जोड़ सकते हैं। यह आमतौर पर उपवर्ग में हुक विधि द्वारा प्राप्त किया जाता है जो सुपरक्लास में टेम्पलेट विधि को ओवरराइड करता है।
- खुला/बंद सिद्धांत | गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा लागू किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता ढांचे का विस्तार कर सकते हैं, लेकिन इसके कोड को संशोधित नहीं कर सकते।
औचित्य
सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के बजाय डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।[2] उदाहरण के लिए, बैंकिंग वेबसाइट विकसित करने के लिए वेब ढांचा का उपयोग करने वाली टीम अनुरोध प्रबंधन और राज्य प्रबंधन के यांत्रिकी के बजाय विशेष रूप से बैंकिंग के लिए कोड लिखने पर ध्यान केंद्रित कर सकती है।
फ्रेमवर्क अक्सर कार्यक्रमों के आकार में वृद्धि करते हैं, घटना जिसे कोड ब्लोट कहा जाता है। ग्राहक-मांग-संचालित अनुप्रयोगों की जरूरतों के कारण, प्रतिस्पर्धी और पूरक ढांचे दोनों कभी-कभी उत्पाद में समाप्त हो जाते हैं। इसके अलावा, उनके एपीआई की जटिलता के कारण, ढांचे का उपयोग करने के लिए अतिरिक्त समय सीखने की आवश्यकता के कारण समग्र विकास समय में इच्छित कमी हासिल नहीं की जा सकती है; यह आलोचना स्पष्ट रूप से मान्य है जब विकास कर्मचारियों द्वारा पहली बार विशेष या नए ढांचे का सामना किया जाता है।[citation needed] यदि इस तरह के ढाँचे का उपयोग बाद के कार्य कार्यों में नहीं किया जाता है, तो ढाँचे को सीखने में लगने वाला समय परियोजना के कर्मचारियों से परिचित उद्देश्य-लिखित कोड से अधिक खर्च हो सकता है; कई प्रोग्रामर आम जरूरतों के लिए उपयोगी बॉयलरप्लेट कोड की प्रतियां रखते हैं।
हालाँकि, बार रूपरेखा सीख लेने के बाद, भविष्य की परियोजनाएँ तेज़ और आसानी से पूरी हो सकती हैं; ढांचे की अवधारणा आकार-फिट-सभी समाधान सेट बनाना है, और परिचितता के साथ, कोड उत्पादन तार्किक रूप से बढ़ना चाहिए। कोड के आकार के बारे में ऐसा कोई दावा नहीं किया गया है, जो अंततः आउटपुट उत्पाद के साथ बंडल किया गया है, न ही इसकी सापेक्ष दक्षता और संक्षिप्तता। किसी भी पुस्तकालय समाधान का उपयोग आवश्यक रूप से अतिरिक्त और अप्रयुक्त बाहरी संपत्तियों को खींचता है जब तक कि सॉफ़्टवेयर कंपाइलर-ऑब्जेक्ट लिंकर नहीं है जो तंग (छोटा, पूर्ण नियंत्रित और निर्दिष्ट) निष्पादन योग्य मॉड्यूल बनाता है।
मुद्दा जारी है, लेकिन उद्योग के दशक से अधिक का अनुभव[citation needed] ने दिखाया है कि सबसे प्रभावी ढांचे वे होते हैं जो सामान्य उद्देश्यों के लिए तीसरे पक्ष द्वारा विकसित सामान्य आकार-फिट-सभी ढांचे का उपयोग करने के बजाय कोड रीफैक्टरिंग|उद्यम के सामान्य कोड को फिर से फैक्टरिंग से विकसित होते हैं। इसका उदाहरण यह होगा कि ऑफिस सूट जैसे एप्लिकेशन पैकेज में यूजर इंटरफेस कैसे सामान्य रूप, अनुभव और डेटा-साझाकरण विशेषताओं और विधियों के लिए बढ़ता है, बार अलग-अलग बंडल किए गए अनुप्रयोगों के रूप में, सूट में एकीकृत हो जाता है जो सख्त है। और छोटा; नया/विकसित सुइट ऐसा उत्पाद हो सकता है जो अभिन्न उपयोगिता पुस्तकालयों और उपयोगकर्ता इंटरफेस को साझा करता है।
विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में महत्वपूर्ण मुद्दा उठाती है। ऐसा ढाँचा बनाना जो सुरुचिपूर्ण हो, बनाम वह जो केवल समस्या का समाधान करता हो, अभी भी विज्ञान के बजाय शिल्प है। सॉफ्टवेयर लालित्य का तात्पर्य स्पष्टता, संक्षिप्तता और थोड़ी बर्बादी (अतिरिक्त या बाहरी कार्यक्षमता, जिनमें से अधिकांश उपयोगकर्ता-परिभाषित है) है। उन रूपरेखाओं के लिए जो कोड उत्पन्न करते हैं, उदाहरण के लिए, लालित्य का मतलब कोड का निर्माण होता है जो उचित जानकार प्रोग्रामर (और जो आसानी से परिवर्तनीय है) के लिए स्वच्छ और समझने योग्य है, जो केवल सही कोड उत्पन्न करता है। लालित्य का मुद्दा यह है कि अपेक्षाकृत कुछ सॉफ्टवेयर फ्रेमवर्क समय की कसौटी पर खरे उतरे हैं: सबसे अच्छी रूपरेखाएँ अंतर्निहित तकनीक के रूप में विकसित होने में सक्षम हैं, जिस पर वे उन्नत बनाए गए थे। वहां भी, विकसित होने के बाद, ऐसे कई पैकेज अंतिम सॉफ्टवेयर को फुलाते हुए विरासत की क्षमताओं को बनाए रखेंगे क्योंकि अन्यथा बदले गए तरीकों को नए तरीकों के साथ समानांतर में रखा गया है।
उदाहरण
सॉफ़्टवेयर ढांचे में आम तौर पर बूटस्ट्रैप उपयोगकर्ता अनुप्रयोगों की सहायता के लिए काफी हाउसकीपिंग और उपयोगिता कोड होते हैं, लेकिन आम तौर पर विशिष्ट समस्या डोमेन पर ध्यान केंद्रित करते हैं, जैसे कि:
- कलात्मक ड्राइंग, संगीत रचना, और यांत्रिक कंप्यूटर एडेड डिजाइन[3][4]
- वित्तीय मॉडलिंग अनुप्रयोग[5]
- पृथ्वी प्रणाली मॉडलिंग अनुप्रयोग[6]
- निर्णय समर्थन प्रणाली[7]
- मीडिया प्लेबैक और संलेखन
- वेब ढांचा
- मध्यस्थ
- कैक्टस फ्रेमवर्क - उच्च प्रदर्शन वैज्ञानिक कंप्यूटिंग।
- आवेदन ढांचा - सामान्य जीयूआई अनुप्रयोग।
- एंटरप्राइज आर्किटेक्चर फ्रेमवर्क
- ओरेकल एप्लीकेशन डेवलपमेंट फ्रेमवर्क
- laravel (PHP फ्रेमवर्क)
- मैलवेयर, उदाहरण के लिए पाइपड्रीम (टूलकिट)
वास्तु
प्री के अनुसार,[8] सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे सॉफ्टवेयर सिस्टम की समग्र वास्तुकला को परिभाषित करते हैं, अर्थात इसके मूल घटक और उनके बीच संबंध। ये एप्लिकेशन ढांचे के किसी भी तात्कालिकता में अपरिवर्तित (जमे हुए) रहते हैं। हॉट स्पॉट उन हिस्सों का प्रतिनिधित्व करते हैं जहां फ्रेमवर्क का उपयोग करने वाले प्रोग्रामर अपने स्वयं के प्रोजेक्ट के लिए विशिष्ट कार्यक्षमता जोड़ने के लिए अपना कोड जोड़ते हैं।
वस्तु-उन्मुख प्रोग्रामिंग | वस्तु-उन्मुख वातावरण में, रूपरेखा में सार वर्ग और वर्ग (कंप्यूटर विज्ञान) # कंक्रीट वर्ग वर्ग (कंप्यूटर विज्ञान) होते हैं। इस तरह के ढांचे के उदाहरण (कंप्यूटर विज्ञान) में मौजूदा वर्ग की वस्तु रचना और उपवर्ग (कंप्यूटर विज्ञान) शामिल हैं।[9] टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को लागू किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को वेरिएंट या हुक विधियों के रूप में जाना जाता है। सुपरक्लास में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं जबकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं।
सॉफ़्टवेयर ढांचे के साथ ठोस सॉफ़्टवेयर सिस्टम विकसित करते समय, डेवलपर्स सिस्टम की विशिष्ट आवश्यकताओं और आवश्यकताओं के अनुसार हॉट स्पॉट का उपयोग करते हैं। सॉफ्टवेयर फ्रेमवर्क हॉलीवुड सिद्धांत पर निर्भर करता है: हमें कॉल न करें, हम आपको कॉल करेंगे।[10][11] इसका अर्थ है कि उपयोगकर्ता-परिभाषित वर्ग (उदाहरण के लिए, नए उपवर्ग) पूर्वनिर्धारित रूपरेखा वर्गों से संदेश प्राप्त करते हैं। डेवलपर्स आमतौर पर सुपरक्लास (कंप्यूटर साइंस) सार विधियों को लागू करके इसे संभालते हैं।
यह भी देखें
- कक्षा (कंप्यूटर विज्ञान)
- डिजाइन पैटर्न (कंप्यूटर विज्ञान)
- अपने आप को मत दोहराओ
- निहित आह्वान
- सॉफ्टवेयर इंजन
संदर्भ
- ↑ Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology
- ↑ "Framework". DocForge. Archived from the original on 7 October 2018. Retrieved 15 December 2008.
- ↑ Vlissides, J M; Linton, M A (1990), "Unidraw: a framework for building domain-specific graphical editors", ACM Transactions on Information Systems, 8 (3): 237–268, doi:10.1145/98188.98197, S2CID 11248368
- ↑ Johnson, R E (1992), "Documenting frameworks using patterns", Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, ACM Press: 63–76
- ↑ Birrer, A; Eggenschwiler, T (1993), "Proceedings of the European conference on object-oriented programming", Frameworks in the financial engineering domain: an experience report, Springer-Verlag, pp. 21–35
- ↑ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), "Architecture of the Earth System Modeling Framework (ESMF)", Computing in Science and Engineering, 6: 18–28, doi:10.1109/MCISE.2004.1255817, S2CID 9311752
- ↑ Gachet, A (2003), "Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools", Journal of Decision Systems, 12 (3): 271–281, doi:10.3166/jds.12.271-280, S2CID 29690836
- ↑ Pree, W (1994), "Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design", Proceedings of the 8th European Conference on Object-Oriented Programming, Lecture Notes in Computer Science, Springer-Verlag, 821: 150–162, CiteSeerX 10.1.1.74.7935, doi:10.1007/BFb0052181, ISBN 978-3-540-58202-1
- ↑ Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 978-0-471-95869-7
- ↑ Larman, C (2001), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd ed.), Prentice Hall, ISBN 978-0-13-092569-5
- ↑ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns. Addison-Wesley. ISBN 0-201-63361-2.
बाहरी संबंध
The dictionary definition of software framework at Wiktionary
Media related to Software frameworks at Wikimedia Commons
