एब्सट्रेक्शन (कंप्यूटर विज्ञान): Difference between revisions
(Created page with "{{short description|Technique for arranging complexity of computer systems}} {{Use dmy dates|date=December 2019}} {{Quote box|quote=The essence of abstraction is preserving in...") |
No edit summary |
||
Line 5: | Line 5: | ||
[[सॉफ्टवेयर इंजीनियरिंग]] और [[कंप्यूटर विज्ञान]] में, अमूर्तन है: | [[सॉफ्टवेयर इंजीनियरिंग]] और [[कंप्यूटर विज्ञान]] में, अमूर्तन है: | ||
* भौतिक, स्थानिक या लौकिक विवरणों | * अधिक महत्व के विवरणों पर ध्यान केंद्रित करने के लिए वस्तुओं या प्रणालियों के अध्ययन में भौतिक, स्थानिक, या लौकिक विवरणों<ref name=":1">{{Cite journal|last1=Colburn|first1=Timothy|last2=Shute|first2=Gary|s2cid=5927969|date=5 June 2007|title=कंप्यूटर विज्ञान में अमूर्तन|journal=Minds and Machines|language=en|volume=17|issue=2|pages=169–184|doi=10.1007/s11023-007-9061-7|issn=0924-6495}}</ref> या विशेषताओं को हटाने या सामान्य बनाने की प्रक्रिया;;<ref name=":0">{{Cite journal|last=Kramer|first=Jeff|s2cid=12481509|date=1 April 2007|title=Is abstraction the key to computing?|journal=Communications of the ACM|volume=50|issue=4|pages=36–42|doi=10.1145/1232743.1232745|issn=0001-0782}}</ref> यह प्रकृति में सामान्यीकरण की प्रक्रिया के समान है; | ||
* विभिन्न गैर-अमूर्त वस्तुओं या अध्ययन प्रणालियों की सामान्य विशेषताओं या विशेषताओं को प्रतिबिंबित करके | * विभिन्न गैर-अमूर्त वस्तुओं या अध्ययन प्रणालियों की सामान्य विशेषताओं या विशेषताओं को प्रतिबिंबित करके अमूर्त अवधारणा वस्तुओं का निर्माण<ref name=":0" />- अमूर्तता की प्रक्रिया का परिणाम है। | ||
सामान्य तौर पर, अमूर्तता, कंप्यूटर विज्ञान और सॉफ्टवेयर विकास में एक मौलिक अवधारणा है।<ref>{{Cite journal|last=Ben-Ari|first=Mordechai|date=1 March 1998|title=कंप्यूटर विज्ञान शिक्षा में रचनावाद|journal=ACM SIGCSE Bulletin|volume=30|issue=1|pages=257, 257–261|doi=10.1145/274790.274308|issn=0097-8418|doi-access=free}}</ref> अमूर्तता की प्रक्रिया को मॉडलिंग के रूप में भी संदर्भित किया जा सकता है और यह सिद्धांत और डिजाइन की अवधारणाओं से निकटता से संबंधित है।<ref>{{Cite journal|last1=Comer|first1=D. E.|last2=Gries|first2=David|last3=Mulder|first3=Michael C.|last4=Tucker|first4=Allen|last5=Turner|first5=A. Joe|last6=Young|first6=Paul R. /Denning|s2cid=723103|date=1 January 1989|title=एक अनुशासन के रूप में कंप्यूटिंग|journal=Communications of the ACM|volume=32|issue=1|pages=9–23|doi=10.1145/63238.63239|issn=0001-0782}}</ref> वास्तविकता के पहलुओं के सामान्यीकरण के अनुसार मॉडलों को अमूर्तता के प्रकार भी माना जा सकता है। | |||
कंप्यूटर विज्ञान में | कंप्यूटर विज्ञान में अमूर्तता गणित में अमूर्तता से निकटता से संबंधित है क्योंकि उनका सामान्य ध्यान वस्तुओं के रूप में अमूर्तता के निर्माण पर है,<ref name=":1" /> लेकिन यह अन्य क्षेत्रों अमूर्त (कला) में उपयोग की जाने वाली अमूर्तता की अन्य धारणाओं से भी संबंधित है।<ref name=":0" /> | ||
अमूर्तन | अमूर्तन वास्तविक दुनिया की वस्तुओं और प्रणालियों, कम्प्यूटेशनल प्रणालियों के नियमों या प्रोग्रामिंग लैंग्वेजओं के नियमों को भी संदर्भित कर सकता है जो अमूर्तता की विशेषताओं को ले जाते हैं या उनका उपयोग करते हैं, जैसे: | ||
* [[कंप्यूटर प्रोग्राम]] के भीतर [[डेटा संरचना]]ओं के कामकाजी प्रतिनिधित्व से उपयोग को अलग करने के लिए डेटा अमूर्त करने के लिए [[डेटा प्रकार]]ों का उपयोग;<ref>{{Cite journal|last=Liskov|first=Barbara|s2cid=14219043|date=1 May 1988|title=Keynote address – data abstraction and hierarchy|journal=ACM SIGPLAN Notices|publisher=ACM|volume=23|pages=17–34|doi=10.1145/62138.62141|isbn=0897912667}}</ref> | * [[कंप्यूटर प्रोग्राम]] के भीतर [[डेटा संरचना]]ओं के कामकाजी प्रतिनिधित्व से उपयोग को अलग करने के लिए डेटा अमूर्त करने के लिए [[डेटा प्रकार]]ों का उपयोग;<ref>{{Cite journal|last=Liskov|first=Barbara|s2cid=14219043|date=1 May 1988|title=Keynote address – data abstraction and hierarchy|journal=ACM SIGPLAN Notices|publisher=ACM|volume=23|pages=17–34|doi=10.1145/62138.62141|isbn=0897912667}}</ref> | ||
* | * प्रक्रियाओं, कार्यों या सबरूटीन्स (उपनेमिका) की अवधारणा जो फंक्शन में नियंत्रण प्रवाह को प्रयुक्त करने के एक विशिष्ट तरीके का प्रतिनिधित्व करती है; | ||
* आमतौर पर एब्स्ट्रैक्शन नाम के नियम जो [[लैम्ब्डा कैलकुलस]] के विभिन्न संस्करणों में [[मुक्त चर और बाध्य चर]] का उपयोग करके [[अभिव्यक्ति (गणित)]] को सामान्यीकृत करते हैं;<ref>{{Cite book|title=The lambda calculus : its syntax and semantics|first=Hendrik Pieter|last=Barendregt|date=1984|publisher=North-Holland|isbn=0444867481|edition=Revised|location=Amsterdam|oclc=10559084}}</ref><ref>{{Cite book|title=प्रकार के साथ लैम्ब्डा कैलकुलस|first=Hendrik Pieter|last=Barendregt|date=2013|publisher=Cambridge University Press|others=Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic.|isbn=9780521766142|location=Cambridge, UK|oclc=852197712}}</ref> | * आमतौर पर एब्स्ट्रैक्शन नाम के नियम जो [[लैम्ब्डा कैलकुलस]] के विभिन्न संस्करणों में [[मुक्त चर और बाध्य चर]] का उपयोग करके [[अभिव्यक्ति (गणित)|व्यंजक (गणित)]] को सामान्यीकृत करते हैं;<ref>{{Cite book|title=The lambda calculus : its syntax and semantics|first=Hendrik Pieter|last=Barendregt|date=1984|publisher=North-Holland|isbn=0444867481|edition=Revised|location=Amsterdam|oclc=10559084}}</ref><ref>{{Cite book|title=प्रकार के साथ लैम्ब्डा कैलकुलस|first=Hendrik Pieter|last=Barendregt|date=2013|publisher=Cambridge University Press|others=Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic.|isbn=9780521766142|location=Cambridge, UK|oclc=852197712}}</ref> | ||
* [[लिस्प (प्रोग्रामिंग भाषा)]] में डेटा संरचनाओं और कार्यक्रमों के अमूर्त के रूप में [[ एस-अभिव्यक्ति ]] का उपयोग;<ref>{{Cite book|last1=Newell|first1=Allen|last2=Simon|first2=Herbert A.|date=1 January 2007|title=Computer science as empirical inquiry: symbols and search|publisher=ACM|pages=1975|doi=10.1145/1283920.1283930|isbn=9781450310499}}</ref> | * [[लिस्प (प्रोग्रामिंग भाषा)|लिस्प (प्रोग्रामिंग लैंग्वेज)]] में डेटा संरचनाओं और कार्यक्रमों के अमूर्त के रूप में [[ एस-अभिव्यक्ति | एस- व्यंजक]] का उपयोग;<ref>{{Cite book|last1=Newell|first1=Allen|last2=Simon|first2=Herbert A.|date=1 January 2007|title=Computer science as empirical inquiry: symbols and search|publisher=ACM|pages=1975|doi=10.1145/1283920.1283930|isbn=9781450310499}}</ref> | ||
* गैर-अमूर्त | * गैर-अमूर्त वर्गों से सामान्य व्यवहार को "अमूर्त वर्गों" में पुनर्गठित करने की प्रक्रिया, जैसा कि ऑब्जेक्ट-ओरिएंटेड सी ++ और जावा प्रोग्रामिंग लैंग्वेजओं में देखा जाता है, उप-वर्गों पर विरासत से अमूर्त तक का उपयोग किया जाता है। | ||
* | |||
==तर्क== | ==तर्क== | ||
कंप्यूटिंग अधिकतर ठोस दुनिया से स्वतंत्र रूप से संचालित होती है। हार्डवेयर गणना का एक मॉडल लागू करता है जो दूसरों के साथ विनिमेय है।<ref>{{Cite journal|last=Floridi|first=Luciano|date=September 2008|title=अमूर्तन के स्तर की विधि|url=http://link.springer.com/10.1007/s11023-008-9113-7|journal=Minds and Machines|language=en|volume=18|issue=3|pages=303–329|doi=10.1007/s11023-008-9113-7|hdl=2299/2998 |s2cid=7522925 |issn=0924-6495}}</ref> | कंप्यूटिंग अधिकतर ठोस दुनिया से स्वतंत्र रूप से संचालित होती है। हार्डवेयर गणना का एक मॉडल लागू करता है जो दूसरों के साथ विनिमेय है।<ref>{{Cite journal|last=Floridi|first=Luciano|date=September 2008|title=अमूर्तन के स्तर की विधि|url=http://link.springer.com/10.1007/s11023-008-9113-7|journal=Minds and Machines|language=en|volume=18|issue=3|pages=303–329|doi=10.1007/s11023-008-9113-7|hdl=2299/2998 |s2cid=7522925 |issn=0924-6495}}</ref> [[सॉफ़्टवेयर]] को आर्किटेक्चर में स्ट्रक्चर्ड किया गया है ताकि मनुष्य एक समय में कुछ मुद्दों पर ध्यान केंद्रित करके विशाल सिस्टम बना सकें। ये आर्किटेक्चर अमूर्तता के विशिष्ट विकल्पों से बने होते हैं। ग्रीनस्पून का दसवां नियम इस बात पर एक सूत्र है कि इस तरह की वास्तुकला अपरिहार्य और जटिल दोनों है। | ||
कंप्यूटिंग में अमूर्तता का एक केंद्रीय रूप | कंप्यूटिंग में अमूर्तता का एक केंद्रीय रूप लैंग्वेज अमूर्तता है: किसी प्रणाली के विशिष्ट पहलुओं को व्यक्त करने के लिए नई कल्पित लैंग्वेज (आर्टिफिशल लैंग्वेज) विकसित की जाती हैं। मॉडलिंग लैंग्वेजएं योजना बनाने में सहायता करती हैं। [[कंप्यूटर भाषा|कंप्यूटर लैंग्वेज]]ओं को कंप्यूटर से संसाधित किया जा सकता है। इस अमूर्त प्रक्रिया का एक उदाहरण मशीन लैंग्वेज से असेंबली लैंग्वेज और उच्च स्तरीय लैंग्वेज तक प्रोग्रामिंग लैंग्वेजओं का पीढ़ीगत विकास है। प्रत्येक चरण को अगले चरण के लिए एक सीढ़ी के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, स्क्रिप्टिंग लैंग्वेजओं और डोमेन-विशिष्ट प्रोग्रामिंग लैंग्वेजओं में लैंग्वेज का अमूर्तन जारी रहता है। | ||
कुछ | एक प्रोग्रामिंग लैंग्वेज के भीतर, कुछ विशेषताएं प्रोग्रामर को नए अमूर्त बनाने देती हैं। इनमें सबरूटीन्स, मॉड्यूल, [[बहुरूपता (कंप्यूटर विज्ञान)|पॉलीमॉरफिस्म (कंप्यूटर विज्ञान)]] और सॉफ्टवेयर कम्पोनेंट्स शामिल हैं। कुछ अन्य अमूर्तताएं जैसे [[सॉफ़्टवेयर डिज़ाइन पैटर्न]] और वास्तुशिल्प शैलियाँ अनुवादक के लिए अदृश्य रहती हैं और केवल सिस्टम के डिज़ाइन में ही काम करती हैं। | ||
कुछ अमूर्तताएं अन्य अमूर्तताओं के साथ अंतर-संचालित करने के लिए डिज़ाइन की गई हैं - उदाहरण के लिए, एक प्रोग्रामिंग | |||
कुछ अमूर्त उन अवधारणाओं की सीमा को सीमित करने का प्रयास करते हैं जिनके बारे में एक प्रोग्रामर को जागरूक होने की आवश्यकता होती है, उन अमूर्तताओं को पूरी तरह से छिपाकर जिन पर वे बने होते हैं। सॉफ्टवेयर इंजीनियर और लेखक जोएल स्पॉल्स्की ने इन प्रयासों की यह दावा करते हुए आलोचना की है कि सभी अमूर्तताएँ लीक से हटकर हैं - कि वे कभी भी नीचे दिए गए विवरणों को पूरी तरह से छिपा नहीं सकते हैं;<ref>{{cite web|url=http://www.joelonsoftware.com/articles/LeakyAbstractions.html|title=लीकी एब्स्ट्रैक्शन का नियम|last1=Spolsky|first=Joel}}</ref> हालाँकि, यह अमूर्तता की उपयोगिता को नकारता नहीं है। | |||
कुछ अमूर्तताएं अन्य अमूर्तताओं के साथ अंतर-संचालित करने के लिए डिज़ाइन की गई हैं - उदाहरण के लिए, एक प्रोग्रामिंग लैंग्वेज में निचले स्तर की लैंग्वेज में कॉल करने के लिए एक [[विदेशी फ़ंक्शन इंटरफ़ेस|फॉरेन फ़ंक्शन इंटरफ़ेस]] हो सकता है। | |||
==अमूर्त विशेषताएं== | ==अमूर्त विशेषताएं== | ||
===प्रोग्रामिंग | ===प्रोग्रामिंग लैंग्वेज=== | ||
{{Main| | {{Main|प्रोग्रामिंग भाषा}} | ||
विभिन्न प्रोग्रामिंग | विभिन्न प्रोग्रामिंग लैंग्वेजएं, लैंग्वेज के लिए इच्छित अनुप्रयोगों के आधार पर, विभिन्न प्रकार के अमूर्तता प्रदान करती हैं। उदाहरण के लिए: | ||
* | * ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेजओं जैसे C++, [[ऑब्जेक्ट पास्कल]], या जावा (प्रोग्रामिंग लैंग्वेज) में, अमूर्तता की अवधारणा स्वयं एक घोषणात्मक कथन बन गई है - सिंटैक्स (प्रोग्रामिंग लैंग्वेजओं) का उपयोग करते हुए <code>''function''(''parameters'') = 0;</code> (सी++ में) या कीवर्ड (कंप्यूटर प्रोग्रामिंग)।<code>abstract</code><ref name="Oracle Java abstract">{{cite web|url=http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html|title=सार विधियाँ और कक्षाएं|website=The Java™ Tutorials|publisher=Oracle|access-date=4 September 2014}}</ref> और<code>interface</code><ref name="Oracle Java interface">{{cite web|url=http://docs.oracle.com/javase/tutorial/java/IandI/interfaceAsType.html|title=एक इंटरफ़ेस को एक प्रकार के रूप में उपयोग करना|website=The Java™ Tutorials|publisher=Oracle|access-date=4 September 2014}}</ref> (जावा में (प्रोग्रामिंग लैंग्वेज))। ऐसी घोषणा के बाद, यह प्रोग्रामर की जिम्मेदारी है कि वह घोषणा के ऑब्जेक्ट (कंप्यूटर विज्ञान) को इंस्टेंट करने के लिए एक क्लास (कंप्यूटर विज्ञान) को लागू करे। | ||
* | * कार्यात्मक प्रोग्रामिंग लैंग्वेजएं आमतौर पर कार्यों से संबंधित अमूर्तता प्रदर्शित करती हैं, जैसे लैम्ब्डा अमूर्तन (किसी शब्द को कुछ चर के फ़ंक्शन में बनाना) और उच्च-क्रम वाले फ़ंक्शन (पैरामीटर फ़ंक्शन होते हैं)।<!-- This has to be merged in the following sections. --> | ||
* लिस्प प्रोग्रामिंग | * लिस्प प्रोग्रामिंग लैंग्वेज परिवार के आधुनिक सदस्य जैसे [[क्लोजर]], स्कीम (प्रोग्रामिंग लैंग्वेज) और [[ सामान्य लिस्प ]] सिंटैक्टिक अमूर्तता की अनुमति देने के लिए मैक्रो (कंप्यूटर विज्ञान) सिंटैक्टिक मैक्रोज़ का समर्थन करते हैं। अन्य प्रोग्रामिंग लैंग्वेजओं जैसे [[स्काला (प्रोग्रामिंग भाषा)|स्काला (प्रोग्रामिंग लैंग्वेज)]] में भी मैक्रोज़, या बहुत समान [[मेटाप्रोग्रामिंग]] विशेषताएं हैं (उदाहरण के लिए, हास्केल (प्रोग्रामिंग लैंग्वेज) में टेम्पलेट हास्केल है, और [[ओकैमल]] में मेटाओकैमल है)। ये एक प्रोग्रामर को [[बॉयलरप्लेट कोड]] को समाप्त करने, बोरिंग फ़ंक्शन कॉल अनुक्रमों को दूर करने, नए नियंत्रण प्रवाह को लागू करने और [[डोमेन-विशिष्ट भाषा|डोमेन-विशिष्ट लैंग्वेज]] | डोमेन विशिष्ट लैंग्वेजओं (डीएसएल) को लागू करने की अनुमति दे सकते हैं, जो डोमेन-विशिष्ट अवधारणाओं को संक्षिप्त और सुरुचिपूर्ण तरीकों से व्यक्त करने की अनुमति देते हैं। . ये सभी, जब सही ढंग से उपयोग किए जाते हैं, तो इच्छित उद्देश्य को और अधिक स्पष्ट करके प्रोग्रामर की दक्षता और कोड की स्पष्टता दोनों में सुधार करते हैं। वाक्यात्मक अमूर्तन का एक परिणाम यह भी है कि किसी भी लिस्प बोली और वास्तव में लगभग किसी भी प्रोग्रामिंग लैंग्वेज को, सिद्धांत रूप में, किसी भी आधुनिक लिस्प में अधिक पारंपरिक प्रोग्रामिंग लैंग्वेजओं की तुलना में काफी कम (लेकिन ज्यादातर मामलों में अभी भी गैर-तुच्छ) प्रयास के साथ लागू किया जा सकता है। जैसे कि [[पायथन (प्रोग्रामिंग भाषा)|पायथन (प्रोग्रामिंग लैंग्वेज)]], [[सी (प्रोग्रामिंग भाषा)|सी (प्रोग्रामिंग लैंग्वेज)]] या जावा (प्रोग्रामिंग लैंग्वेज)। | ||
=== | ===स्पेसिफिकेशन विधियाँ=== | ||
{{Main| | {{Main|औपचारिक विशिष्टता (स्पेसिफिकेशन)}} | ||
स्पेसिफिकेशन ने सॉफ्टवेयर सिस्टम को औपचारिक रूप से निर्दिष्ट करने के लिए विभिन्न तरीके विकसित किए हैं। कुछ ज्ञात विधियों में शामिल हैं: | |||
* सार-मॉडल आधारित विधि ( | * सार-मॉडल आधारित विधि (VDM, Z); | ||
* बीजगणितीय तकनीकें ( | * बीजगणितीय तकनीकें (Larch, CLEAR, OBJ, ACT ONE, CASL); | ||
* प्रक्रिया-आधारित तकनीकें (LOTOS, SDL, | * प्रक्रिया-आधारित तकनीकें (LOTOS, SDL, Estelle); | ||
* ट्रेस-आधारित तकनीकें ( | * ट्रेस-आधारित तकनीकें (SPECIAL, TAM); | ||
* ज्ञान-आधारित तकनीकें ( | * ज्ञान-आधारित तकनीकें (Refine, Gist)। | ||
=== | ===स्पेसिफिकेशन लैंग्वेज=== | ||
{{Main| | {{Main|स्पेसिफिकेशन लैंग्वेज}} | ||
स्पेसिफिकेशन लैंग्वेज आम तौर पर एक या दूसरे प्रकार के अमूर्त पर निर्भर करती हैं, क्योंकि स्पेसिफिकेशन को आम तौर पर किसी परियोजना में अंतिम कार्यान्वयन की तुलना में पहले (और अधिक अमूर्त स्तर पर) परिभाषित किया जाता है। उदाहरण के लिए, यूएमएल स्पेसिफिकेशन लैंग्वेज, अमूर्त वर्गों की परिलैंग्वेज की अनुमति देती है, जो एक वॉटरफॉल परियोजना में, परियोजना के वास्तुकला और स्पेसिफिकेशन चरण के दौरान अमूर्त रहते हैं। | |||
==नियंत्रण अमूर्तन== | ==नियंत्रण अमूर्तन== | ||
{{Main| | {{Main|कण्ट्रोल फ्लो}} | ||
प्रोग्रामिंग | प्रोग्रामिंग लैंग्वेज अपने उपयोग के मुख्य उद्देश्यों में से एक के रूप में नियंत्रण अमूर्तता प्रदान करती हैं। कंप्यूटर मशीनें बहुत निम्न स्तर पर संचालन को समझती हैं जैसे कि कुछ बिट्स को मेमोरी के एक स्थान से दूसरे स्थान पर ले जाना और बिट्स के दो अनुक्रमों का योग उत्पन्न करना। प्रोग्रामिंग लैंग्वेज इसे उच्च स्तर पर करने की अनुमति देती हैं। उदाहरण के लिए, [[पास्कल (प्रोग्रामिंग भाषा)|पास्कल (प्रोग्रामिंग लैंग्वेज)]] जैसी शैली में लिखे गए इस कथन पर विचार करें: | ||
:<code>a := (1 + 2) * 5</code> | :<code>a := (1 + 2) * 5</code> | ||
एक इंसान के लिए, यह काफी सरल और स्पष्ट गणना लगती है (एक | एक इंसान के लिए, यह काफी सरल और स्पष्ट गणना लगती है ''("एक प्लस दो तीन है, पांच गुना पंद्रह है")''। हालाँकि, इस मूल्यांकन को करने के लिए आवश्यक निम्न-स्तरीय कदम, और मान "15" लौटाना, और फिर उस मान को वेरिएबल "ए" पर निर्दिष्ट करना, वास्तव में काफी सूक्ष्म और जटिल हैं। मानों को बाइनरी प्रतिनिधित्व में परिवर्तित करने की आवश्यकता होती है (अक्सर किसी की सोच से कहीं अधिक जटिल कार्य) और गणनाओं को (संकलक या दुभाषिया द्वारा) असेंबली निर्देशों में विघटित किया जाता है (फिर से, जो प्रोग्रामर के लिए बहुत कम सहज होते हैं: संचालन जैसे एक बाइनरी रजिस्टर को बाईं ओर स्थानांतरित करना, या एक रजिस्टर की सामग्री के बाइनरी पूरक को दूसरे में जोड़ना, बिल्कुल वैसा नहीं है जैसा मनुष्य जोड़ या गुणा के अमूर्त अंकगणितीय संचालन के बारे में सोचते हैं)। अंत में, "a" लेबल वाले वेरिएबल को "15" का परिणामी मान निर्दिष्ट करना, ताकि "a" का उपयोग बाद में किया जा सके, इसमें वेरिएबल के लेबल और भौतिक में परिणामी स्थान को देखने के अतिरिक्त 'पर्दे के पीछे' चरण शामिल होते हैं। या वर्चुअल मेमोरी, उस मेमोरी स्थान पर "15" के बाइनरी प्रतिनिधित्व को संग्रहीत करना, आदि। | ||
नियंत्रण अमूर्तता के बिना, एक प्रोग्रामर को हर बार सभी रजिस्टर/बाइनरी-स्तरीय चरणों को निर्दिष्ट करने की आवश्यकता होगी, जब वे बस कुछ संख्याओं को जोड़ना या गुणा करना चाहते थे और परिणाम को एक चर में निर्दिष्ट करना चाहते थे। प्रयास के | नियंत्रण अमूर्तता के बिना, एक प्रोग्रामर को हर बार सभी रजिस्टर/बाइनरी-स्तरीय चरणों को निर्दिष्ट करने की आवश्यकता होगी, जब वे बस कुछ संख्याओं को जोड़ना या गुणा करना चाहते थे और परिणाम को एक चर में निर्दिष्ट करना चाहते थे। प्रयास के इस प्रकार के दोहराव के दो गंभीर नकारात्मक परिणाम होते हैं: | ||
# यह प्रोग्रामर को हर बार समान ऑपरेशन की आवश्यकता होने पर लगातार सामान्य कार्यों को दोहराने के लिए मजबूर करता है | # यह प्रोग्रामर को हर बार समान ऑपरेशन की आवश्यकता होने पर लगातार सामान्य कार्यों को दोहराने के लिए मजबूर करता है | ||
# यह प्रोग्रामर को विशेष हार्डवेयर और निर्देश सेट के लिए प्रोग्राम करने के लिए बाध्य करता है | # यह प्रोग्रामर को विशेष हार्डवेयर और निर्देश सेट के लिए प्रोग्राम करने के लिए बाध्य करता है | ||
=== | ===स्ट्रक्चर्ड प्रोग्रामिंग=== | ||
{{Main| | {{Main|संरचित प्रोग्रामिंग (स्ट्रक्चर्ड प्रोग्रामिंग)}} | ||
स्ट्रक्चर्ड प्रोग्रामिंग में जटिल प्रोग्राम कार्यों को स्पष्ट प्रवाह-नियंत्रण और कम्पोनेन्ट के बीच इंटरफेस के साथ छोटे टुकड़ों में विभाजित करना शामिल है, जिससे साइड-इफेक्ट्स की जटिलता क्षमता में कमी आती है। | |||
एक सरल कार्यक्रम में, इसका उद्देश्य यह सुनिश्चित करना हो सकता है कि लूप में एकल या स्पष्ट निकास बिंदु हों और (जहां संभव हो) कार्यों और प्रक्रियाओं से एकल निकास बिंदु हों। | एक सरल कार्यक्रम में, इसका उद्देश्य यह सुनिश्चित करना हो सकता है कि लूप में एकल या स्पष्ट निकास बिंदु हों और (जहां संभव हो) कार्यों और प्रक्रियाओं से एकल निकास बिंदु हों। | ||
Line 82: | Line 85: | ||
* सबसे ऊपरी स्तर पर विशिष्ट अंतिम-उपयोगकर्ता संचालन का एक मेनू हो सकता है। | * सबसे ऊपरी स्तर पर विशिष्ट अंतिम-उपयोगकर्ता संचालन का एक मेनू हो सकता है। | ||
* उसके भीतर कर्मचारियों के हस्ताक्षर करने और बंद करने या चेक प्रिंट करने जैसे कार्यों के लिए स्टैंडअलोन निष्पादन योग्य या लाइब्रेरी हो सकती हैं। | * उसके भीतर कर्मचारियों के हस्ताक्षर करने और बंद करने या चेक प्रिंट करने जैसे कार्यों के लिए स्टैंडअलोन निष्पादन योग्य या लाइब्रेरी हो सकती हैं। | ||
* उन स्टैंडअलोन | * उन स्टैंडअलोन कम्पोनेन्ट में से प्रत्येक के भीतर कई अलग-अलग स्रोत फ़ाइलें हो सकती हैं, प्रत्येक में समस्या के एक हिस्से को संभालने के लिए प्रोग्राम कोड होता है, प्रोग्राम के अन्य हिस्सों के लिए केवल चयनित इंटरफ़ेस उपलब्ध होते हैं। प्रोग्राम पर एक साइन में प्रत्येक डेटा एंट्री स्क्रीन और डेटाबेस इंटरफ़ेस के लिए स्रोत फ़ाइलें हो सकती हैं (जो स्वयं एक स्टैंडअलोन थर्ड पार्टी लाइब्रेरी या लाइब्रेरी रूटीन का एक स्थिर रूप से जुड़ा हुआ सेट हो सकता है)। | ||
*या तो डेटाबेस या पेरोल एप्लिकेशन को जहाज और तट के बीच डेटा के आदान-प्रदान की प्रक्रिया शुरू करनी होगी, और उस डेटा ट्रांसफर कार्य में अक्सर कई अन्य घटक शामिल होंगे। | *या तो डेटाबेस या पेरोल एप्लिकेशन को जहाज और तट के बीच डेटा के आदान-प्रदान की प्रक्रिया शुरू करनी होगी, और उस डेटा ट्रांसफर कार्य में अक्सर कई अन्य घटक शामिल होंगे। | ||
Line 92: | Line 95: | ||
डेटा अमूर्तन डेटा प्रकार के अमूर्त गुणों और इसके कार्यान्वयन के ठोस विवरण के बीच स्पष्ट अलगाव को लागू करता है। अमूर्त गुण वे हैं जो क्लाइंट कोड को दिखाई देते हैं जो डेटा प्रकार का उपयोग करते हैं - डेटा प्रकार के लिए इंटरफ़ेस - जबकि ठोस कार्यान्वयन पूरी तरह से निजी रखा जाता है, और वास्तव में बदल सकता है, उदाहरण के लिए समय के साथ दक्षता में सुधार शामिल करना। विचार यह है कि ऐसे परिवर्तनों का क्लाइंट कोड पर कोई प्रभाव नहीं पड़ता है, क्योंकि उनमें अमूर्त व्यवहार में कोई अंतर नहीं होता है। | डेटा अमूर्तन डेटा प्रकार के अमूर्त गुणों और इसके कार्यान्वयन के ठोस विवरण के बीच स्पष्ट अलगाव को लागू करता है। अमूर्त गुण वे हैं जो क्लाइंट कोड को दिखाई देते हैं जो डेटा प्रकार का उपयोग करते हैं - डेटा प्रकार के लिए इंटरफ़ेस - जबकि ठोस कार्यान्वयन पूरी तरह से निजी रखा जाता है, और वास्तव में बदल सकता है, उदाहरण के लिए समय के साथ दक्षता में सुधार शामिल करना। विचार यह है कि ऐसे परिवर्तनों का क्लाइंट कोड पर कोई प्रभाव नहीं पड़ता है, क्योंकि उनमें अमूर्त व्यवहार में कोई अंतर नहीं होता है। | ||
उदाहरण के लिए, कोई एक [[अमूर्त डेटा प्रकार]] को परिभाषित कर सकता है जिसे लुकअप टेबल कहा जाता है जो विशिष्ट रूप से मानों के साथ कुंजियों को जोड़ता है, और जिसमें मानों को उनकी संबंधित कुंजियों को निर्दिष्ट करके पुनर्प्राप्त किया जा सकता है। ऐसी लुकअप | उदाहरण के लिए, कोई एक [[अमूर्त डेटा प्रकार]] को परिभाषित कर सकता है जिसे लुकअप टेबल कहा जाता है जो विशिष्ट रूप से मानों के साथ कुंजियों को जोड़ता है, और जिसमें मानों को उनकी संबंधित कुंजियों को निर्दिष्ट करके पुनर्प्राप्त किया जा सकता है। ऐसी लुकअप टेबल को विभिन्न तरीकों से कार्यान्वित किया जा सकता है: एक [[हैश तालिका|हैश टेबल]], एक [[बाइनरी सर्च ट्री]], या यहां तक कि (कुंजी: मान) जोड़े की एक सरल रैखिक [[सूची (कंप्यूटिंग)]] के रूप में। जहां तक क्लाइंट कोड का सवाल है, प्रत्येक मामले में प्रकार के अमूर्त गुण समान हैं। | ||
यह सब सबसे पहले इंटरफ़ेस का विवरण प्राप्त करने पर निर्भर करता है, क्योंकि वहां कोई भी बदलाव क्लाइंट कोड पर बड़ा प्रभाव डाल सकता है। इसे देखने का एक तरीका: इंटरफ़ेस डेटा प्रकार और क्लाइंट कोड के बीच सहमत व्यवहार पर एक अनुबंध बनाता है; अनुबंध में जो कुछ भी नहीं लिखा गया है, वह बिना किसी सूचना के परिवर्तन के अधीन है। | |||
== मैनुअल डेटा अमूर्त == | == मैनुअल डेटा अमूर्त == | ||
जबकि अधिकांश डेटा | जबकि अधिकांश डेटा अमूर्त कंप्यूटर विज्ञान और स्वचालन के माध्यम से होता है, ऐसे समय होते हैं जब यह प्रक्रिया मैन्युअल रूप से और प्रोग्रामिंग हस्तक्षेप के बिना की जाती है। इसे समझने का एक तरीका साहित्य की व्यवस्थित समीक्षा करने की प्रक्रिया के भीतर डेटा अमूर्तन के माध्यम से है। इस पद्धति में, मेटा-विश्लेषण करते समय डेटा को एक या कई अमूर्तकर्ताओं द्वारा अमूर्त किया जाता है, जिसमें दोहरे डेटा अमूर्तन के माध्यम से त्रुटियों को कम किया जाता है, जिसके बाद स्वतंत्र जाँच की जाती है, जिसे निर्णय के रूप में जाना जाता है।<ref>{{Cite journal|last1=E|first1=Jian‐Yu|last2=Saldanha|first2=Ian J.|last3=Canner|first3=Joseph|last4=Schmid|first4=Christopher H.|last5=Le|first5=Jimmy T.|last6=Li|first6=Tianjing|date=2020|title=व्यवस्थित समीक्षाओं में डेटा को अमूर्त करने में त्रुटियों को कम करने में डेटा अमूर्त के अनुभव के बजाय निर्णय अधिक मायने रखता है|journal=Research Synthesis Methods|language=en|volume=11|issue=3|pages=354–362|doi=10.1002/jrsm.1396|pmid=31955502|s2cid=210829764 |issn=1759-2879}}</ref> | ||
==ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में अमूर्तन== | ==ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में अमूर्तन== | ||
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सिद्धांत में, अमूर्तता में उन वस्तुओं को परिभाषित करने की सुविधा शामिल होती है जो अमूर्त अभिनेताओं का प्रतिनिधित्व करती हैं जो काम कर सकते हैं, रिपोर्ट कर सकते हैं और अपनी स्थिति बदल सकते हैं, और सिस्टम में अन्य वस्तुओं के साथ संचार कर सकते हैं। [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] शब्द [[राज्य (कंप्यूटर विज्ञान)]] विवरणों को छिपाने को संदर्भित करता है, लेकिन डेटा के साथ ''व्यवहार'' को सबसे मजबूती से जोड़ने के लिए पहले की प्रोग्रामिंग लैंग्वेजओं से ''डेटा प्रकार'' की अवधारणा का विस्तार करता है, और विभिन्न डेटा प्रकारों के इंटरैक्ट करने के तरीके को मानकीकृत करना, अमूर्तन की शुरुआत है। जब अमूर्तता परिभाषित कार्यों में आगे बढ़ती है, जिससे विभिन्न प्रकार की वस्तुओं को प्रतिस्थापित किया जा सकता है, तो इसे बहुरूपता (कंप्यूटर विज्ञान) कहा जाता है। जब यह विपरीत दिशा में आगे बढ़ता है, प्रकारों या वर्गों के अंदर, रिश्तों के एक जटिल सेट को सरल बनाने के लिए उन्हें स्ट्रक्चर्ड करता है, तो इसे [[ प्रतिनिधिमंडल (वस्तु-उन्मुख प्रोग्रामिंग) ]] या इनहेरिटेंस (कंप्यूटर विज्ञान) कहा जाता है। | |||
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सिद्धांत में, अमूर्तता में उन वस्तुओं को परिभाषित करने की सुविधा शामिल होती है जो अमूर्त अभिनेताओं का प्रतिनिधित्व करती हैं जो काम कर सकते हैं, रिपोर्ट कर सकते हैं और अपनी स्थिति बदल सकते हैं, और सिस्टम में अन्य वस्तुओं के साथ संचार कर सकते हैं। [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] शब्द [[राज्य (कंप्यूटर विज्ञान)]] विवरणों को छिपाने को संदर्भित करता है, लेकिन डेटा के साथ ''व्यवहार'' को सबसे मजबूती से जोड़ने के लिए पहले की प्रोग्रामिंग | |||
विभिन्न ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग | विभिन्न ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेजएं अमूर्तता के लिए समान सुविधाएं प्रदान करती हैं, सभी [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता]] (कंप्यूटर विज्ञान) की एक सामान्य रणनीति का समर्थन करने के लिए, जिसमें समान या समान भूमिका में [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में कॉन्फ़िगरेशन]] प्रकार का दूसरे के लिए प्रतिस्थापन शामिल है। . यद्यपि आम तौर पर समर्थित नहीं है, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग या छवि या पैकेज में एक कॉन्फ़िगरेशन संकलन-समय, [[ लिंक समय ]], या [[ लोड होने का समय ]] पर इनमें से कई नामों को पूर्व निर्धारित कर सकता है। इससे रन टाइम (प्रोग्राम जीवनचक्र चरण)|रन-टाइम पर बदलने के लिए ऐसी [[नाम बंधन]] ही बचेगी। | ||
उदाहरण के लिए, [[सामान्य लिस्प ऑब्जेक्ट सिस्टम]] या सेल्फ (प्रोग्रामिंग | उदाहरण के लिए, [[सामान्य लिस्प ऑब्जेक्ट सिस्टम]] या सेल्फ (प्रोग्रामिंग लैंग्वेज)[[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग टाइप करें]] क्लास-इंस्टेंस भेद की कम सुविधा और बहुरूपता के लिए प्रतिनिधिमंडल का अधिक उपयोग करता है। [[[[स्वयं (प्रोग्रामिंग भाषा)|स्वयं (प्रोग्रामिंग लैंग्वेज)]]]] की साझा कार्यात्मक विरासत के साथ बेहतर ढंग से फिट होने के लिए व्यक्तिगत वस्तुओं और कार्यों को अधिक लचीले ढंग से अमूर्त किया जाता है। | ||
C++ एक और चरम का उदाहरण देता है: यह [[सामान्य प्रोग्रामिंग]] और विधि ओवरलोडिंग और संकलन-समय पर अन्य स्थैतिक बाइंडिंग पर बहुत अधिक निर्भर करता है, जिसके बदले में कुछ लचीलेपन की समस्याएं होती हैं। | C++ एक और चरम का उदाहरण देता है: यह [[सामान्य प्रोग्रामिंग]] और विधि ओवरलोडिंग और संकलन-समय पर अन्य स्थैतिक बाइंडिंग पर बहुत अधिक निर्भर करता है, जिसके बदले में कुछ लचीलेपन की समस्याएं होती हैं। | ||
Line 113: | Line 114: | ||
यद्यपि ये उदाहरण समान अमूर्तता को प्राप्त करने के लिए वैकल्पिक रणनीतियों की पेशकश करते हैं, लेकिन वे कोड में अमूर्त संज्ञाओं का समर्थन करने की आवश्यकता को मौलिक रूप से नहीं बदलते हैं - सभी प्रोग्रामिंग क्रियाओं को कार्यों के रूप में, संज्ञाओं को डेटा संरचनाओं के रूप में, और या तो प्रक्रियाओं के रूप में अमूर्त करने की क्षमता पर निर्भर करती हैं। | यद्यपि ये उदाहरण समान अमूर्तता को प्राप्त करने के लिए वैकल्पिक रणनीतियों की पेशकश करते हैं, लेकिन वे कोड में अमूर्त संज्ञाओं का समर्थन करने की आवश्यकता को मौलिक रूप से नहीं बदलते हैं - सभी प्रोग्रामिंग क्रियाओं को कार्यों के रूप में, संज्ञाओं को डेटा संरचनाओं के रूप में, और या तो प्रक्रियाओं के रूप में अमूर्त करने की क्षमता पर निर्भर करती हैं। | ||
उदाहरण के लिए एक नमूना जावा (प्रोग्रामिंग | उदाहरण के लिए एक नमूना जावा (प्रोग्रामिंग लैंग्वेज) टुकड़े पर विचार करें जो कुछ सामान्य खेत जानवरों को उनकी भूख और भोजन के सरल पहलुओं को मॉडल करने के लिए उपयुक्त अमूर्त स्तर पर प्रस्तुत करता है। यह एक को परिभाषित करता है <code>Animal</code> जानवर की स्थिति और उसके कार्यों दोनों का प्रतिनिधित्व करने वाला वर्ग: | ||
<syntaxhighlight lang="java"> | <syntaxhighlight lang="java"> | ||
Line 134: | Line 135: | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
उपरोक्त | उपरोक्त परिलैंग्वेज के साथ, कोई भी प्रकार की वस्तुएं बना सकता है {{samp|Animal}} और उनकी विधियों को इस प्रकार कॉल करें: | ||
<syntaxhighlight lang="java"> | <syntaxhighlight lang="java"> | ||
Line 151: | Line 152: | ||
यदि किसी को जानवरों के अधिक विभेदित पदानुक्रम की आवश्यकता है - मान लीजिए, जो लोग अपने जीवन के अंत में मांस के अलावा कुछ भी नहीं देते हैं, उनसे दूध प्रदान करने वालों को अलग करना है - यह अमूर्तता का एक मध्यवर्ती स्तर है, शायद डेयरीएनिमल (गाय, बकरी) जो ऐसा करेगा अच्छा दूध देने के लिए उपयुक्त खाद्य पदार्थ खाएं, और मीटएनिमल (सूअर, स्टीयर) जो सर्वोत्तम मांस-गुणवत्ता देने के लिए खाद्य पदार्थ खाएंगे। | यदि किसी को जानवरों के अधिक विभेदित पदानुक्रम की आवश्यकता है - मान लीजिए, जो लोग अपने जीवन के अंत में मांस के अलावा कुछ भी नहीं देते हैं, उनसे दूध प्रदान करने वालों को अलग करना है - यह अमूर्तता का एक मध्यवर्ती स्तर है, शायद डेयरीएनिमल (गाय, बकरी) जो ऐसा करेगा अच्छा दूध देने के लिए उपयुक्त खाद्य पदार्थ खाएं, और मीटएनिमल (सूअर, स्टीयर) जो सर्वोत्तम मांस-गुणवत्ता देने के लिए खाद्य पदार्थ खाएंगे। | ||
इस तरह के एक अमूर्तन से एप्लिकेशन कोडर के लिए भोजन के प्रकार को निर्दिष्ट करने की आवश्यकता समाप्त हो सकती है, ताकि वे इसके बजाय भोजन शेड्यूल पर ध्यान केंद्रित कर सकें। दोनों वर्गों को इनहेरिटेंस (कंप्यूटर विज्ञान) का उपयोग करके या अकेले खड़ा किया जा सकता है, और प्रोग्रामर दो प्रकारों के बीच बहुरूपता (कंप्यूटर विज्ञान) की अलग-अलग डिग्री को परिभाषित कर सकता है। ये सुविधाएं | इस तरह के एक अमूर्तन से एप्लिकेशन कोडर के लिए भोजन के प्रकार को निर्दिष्ट करने की आवश्यकता समाप्त हो सकती है, ताकि वे इसके बजाय भोजन शेड्यूल पर ध्यान केंद्रित कर सकें। दोनों वर्गों को इनहेरिटेंस (कंप्यूटर विज्ञान) का उपयोग करके या अकेले खड़ा किया जा सकता है, और प्रोग्रामर दो प्रकारों के बीच बहुरूपता (कंप्यूटर विज्ञान) की अलग-अलग डिग्री को परिभाषित कर सकता है। ये सुविधाएं लैंग्वेजओं के बीच काफी भिन्न होती हैं, लेकिन सामान्य तौर पर प्रत्येक लैंग्वेज कुछ भी हासिल कर सकती है जो किसी अन्य के साथ संभव है। बड़ी संख्या में ऑपरेशन ओवरलोड, डेटा प्रकार के आधार पर डेटा, संकलन-समय पर वंशानुक्रम की किसी भी डिग्री या बहुरूपता प्राप्त करने के अन्य साधनों के समान प्रभाव डाल सकते हैं। क्लास नोटेशन बस एक कोडर की सुविधा है। | ||
===वस्तु-उन्मुख डिज़ाइन=== | ===वस्तु-उन्मुख डिज़ाइन=== | ||
Line 161: | Line 162: | ||
==विचार== | ==विचार== | ||
प्रोग्रामिंग | प्रोग्रामिंग लैंग्वेजओं, औपचारिक तरीकों या [[अमूर्त व्याख्या]] के औपचारिक शब्दार्थ पर चर्चा करते समय, अमूर्तता, देखे गए प्रोग्राम व्यवहारों की कम विस्तृत, लेकिन सुरक्षित परिलैंग्वेज पर विचार करने के कार्य को संदर्भित करती है। उदाहरण के लिए, कोई निष्पादन के सभी मध्यवर्ती चरणों पर विचार करने के बजाय केवल प्रोग्राम निष्पादन के अंतिम परिणाम को देख सकता है। अमूर्तन को निष्पादन के एक ठोस (अधिक सटीक) मॉडल के रूप में परिभाषित किया गया है। | ||
किसी संपत्ति के संबंध में अमूर्तता सटीक या विश्वसनीय हो सकती है यदि कोई व्यक्ति संपत्ति के बारे में किसी प्रश्न का उत्तर ठोस या अमूर्त मॉडल पर समान रूप से अच्छी तरह से दे सकता है। उदाहरण के लिए, यदि कोई जानना चाहता है कि केवल पूर्णांक +, -, × वाले गणितीय | किसी संपत्ति के संबंध में अमूर्तता सटीक या विश्वसनीय हो सकती है यदि कोई व्यक्ति संपत्ति के बारे में किसी प्रश्न का उत्तर ठोस या अमूर्त मॉडल पर समान रूप से अच्छी तरह से दे सकता है। उदाहरण के लिए, यदि कोई जानना चाहता है कि केवल पूर्णांक +, -, × वाले गणितीय व्यंजक के मूल्यांकन का परिणाम [[मॉड्यूलर अंकगणित]] ''एन'' के बराबर है, तो उसे केवल सभी ऑपरेशन मॉड्यूलो ''एन'' करने की जरूरत है। (इस अमूर्तन का एक परिचित रूप [[नौ को बाहर निकालना]] है)। | ||
हालाँकि, सार-संक्षेप, हालांकि जरूरी नहीं कि सटीक हों, ठोस होने चाहिए। अर्थात्, उनसे ठोस उत्तर प्राप्त करना संभव होना चाहिए - भले ही अमूर्तता केवल [[अनिर्णीत समस्या]] का परिणाम दे सकती है। उदाहरण के लिए, किसी कक्षा में छात्रों को उनकी न्यूनतम और अधिकतम आयु से अलग किया जा सकता है; यदि कोई पूछता है कि क्या कोई निश्चित व्यक्ति उस वर्ग का है, तो वह बस उस व्यक्ति की उम्र की तुलना न्यूनतम और अधिकतम उम्र से कर सकता है; यदि उसकी आयु सीमा से बाहर है, तो कोई भी सुरक्षित रूप से उत्तर दे सकता है कि वह व्यक्ति उस वर्ग से संबंधित नहीं है; यदि ऐसा नहीं है, तो कोई केवल यही उत्तर दे सकता है कि मैं नहीं जानता। | हालाँकि, सार-संक्षेप, हालांकि जरूरी नहीं कि सटीक हों, ठोस होने चाहिए। अर्थात्, उनसे ठोस उत्तर प्राप्त करना संभव होना चाहिए - भले ही अमूर्तता केवल [[अनिर्णीत समस्या]] का परिणाम दे सकती है। उदाहरण के लिए, किसी कक्षा में छात्रों को उनकी न्यूनतम और अधिकतम आयु से अलग किया जा सकता है; यदि कोई पूछता है कि क्या कोई निश्चित व्यक्ति उस वर्ग का है, तो वह बस उस व्यक्ति की उम्र की तुलना न्यूनतम और अधिकतम उम्र से कर सकता है; यदि उसकी आयु सीमा से बाहर है, तो कोई भी सुरक्षित रूप से उत्तर दे सकता है कि वह व्यक्ति उस वर्ग से संबंधित नहीं है; यदि ऐसा नहीं है, तो कोई केवल यही उत्तर दे सकता है कि मैं नहीं जानता। | ||
किसी प्रोग्रामिंग | किसी प्रोग्रामिंग लैंग्वेज में शामिल अमूर्तता का स्तर इसकी समग्र [[प्रयोज्य]]ता को प्रभावित कर सकता है। [[संज्ञानात्मक आयाम]] ढांचे में औपचारिकता में ''अमूर्त ढाल'' की अवधारणा शामिल है। यह ढांचा एक प्रोग्रामिंग लैंग्वेज के डिजाइनर को अमूर्तता और डिजाइन की अन्य विशेषताओं के बीच व्यापार-बंद का अध्ययन करने की अनुमति देता है, और अमूर्तता में परिवर्तन लैंग्वेज की उपयोगिता को कैसे प्रभावित करते हैं। | ||
कंप्यूटर प्रोग्राम के साथ व्यवहार करते समय सार-संक्षेप उपयोगी साबित हो सकते हैं, क्योंकि कंप्यूटर प्रोग्राम के गैर-तुच्छ गुण अनिवार्य रूप से अनिर्णीत समस्या हैं (राइस का प्रमेय देखें)। परिणामस्वरूप, कंप्यूटर प्रोग्राम के व्यवहार के बारे में जानकारी प्राप्त करने के लिए स्वचालित तरीकों को या तो समाप्ति (कुछ अवसरों पर, वे विफल हो सकते हैं, क्रैश हो सकते हैं या कभी परिणाम नहीं दे सकते हैं), सुदृढ़ता (वे गलत जानकारी प्रदान कर सकते हैं), या सटीकता ( वे कुछ प्रश्नों का उत्तर दे सकते हैं जिन्हें मैं नहीं जानता)। | कंप्यूटर प्रोग्राम के साथ व्यवहार करते समय सार-संक्षेप उपयोगी साबित हो सकते हैं, क्योंकि कंप्यूटर प्रोग्राम के गैर-तुच्छ गुण अनिवार्य रूप से अनिर्णीत समस्या हैं (राइस का प्रमेय देखें)। परिणामस्वरूप, कंप्यूटर प्रोग्राम के व्यवहार के बारे में जानकारी प्राप्त करने के लिए स्वचालित तरीकों को या तो समाप्ति (कुछ अवसरों पर, वे विफल हो सकते हैं, क्रैश हो सकते हैं या कभी परिणाम नहीं दे सकते हैं), सुदृढ़ता (वे गलत जानकारी प्रदान कर सकते हैं), या सटीकता ( वे कुछ प्रश्नों का उत्तर दे सकते हैं जिन्हें मैं नहीं जानता)। | ||
Line 176: | Line 177: | ||
{{Main|Abstraction layer}} | {{Main|Abstraction layer}} | ||
कंप्यूटर विज्ञान आमतौर पर अमूर्तता के स्तर (या, कम सामान्यतः, परतें) प्रस्तुत करता है, जिसमें प्रत्येक स्तर एक ही जानकारी और प्रक्रियाओं के एक अलग मॉडल का प्रतिनिधित्व करता है, लेकिन अलग-अलग मात्रा में विवरण के साथ। प्रत्येक स्तर | कंप्यूटर विज्ञान आमतौर पर अमूर्तता के स्तर (या, कम सामान्यतः, परतें) प्रस्तुत करता है, जिसमें प्रत्येक स्तर एक ही जानकारी और प्रक्रियाओं के एक अलग मॉडल का प्रतिनिधित्व करता है, लेकिन अलग-अलग मात्रा में विवरण के साथ। प्रत्येक स्तर व्यंजक की एक प्रणाली का उपयोग करता है जिसमें वस्तुओं और रचनाओं का एक अनूठा सेट शामिल होता है जो केवल एक विशेष डोमेन पर लागू होता है। | ||
<ref>[[Luciano Floridi]], [http://www.cs.ox.ac.uk/activities/ieg/research_reports/ieg_rr221104.pdf ''Levellism and the Method of Abstraction''] | <ref>[[Luciano Floridi]], [http://www.cs.ox.ac.uk/activities/ieg/research_reports/ieg_rr221104.pdf ''Levellism and the Method of Abstraction''] | ||
IEG – Research Report 22.11.04</ref> | IEG – Research Report 22.11.04</ref> | ||
प्रत्येक अपेक्षाकृत अमूर्त, उच्च स्तर अपेक्षाकृत ठोस, निचले स्तर पर निर्मित होता है, जो तेजी से दानेदार प्रतिनिधित्व प्रदान करता है। उदाहरण के लिए, गेट्स इलेक्ट्रॉनिक सर्किट पर, बाइनरी गेट्स पर, मशीन लैंग्वेज बाइनरी पर, प्रोग्रामिंग लैंग्वेज मशीन लैंग्वेज पर, एप्लिकेशन और ऑपरेटिंग सिस्टम प्रोग्रामिंग लैंग्वेज पर बनते हैं। प्रत्येक स्तर सन्निहित है, लेकिन उसके नीचे के स्तर से निर्धारित नहीं होता है, जिससे यह वर्णन की | प्रत्येक अपेक्षाकृत अमूर्त, उच्च स्तर अपेक्षाकृत ठोस, निचले स्तर पर निर्मित होता है, जो तेजी से दानेदार प्रतिनिधित्व प्रदान करता है। उदाहरण के लिए, गेट्स इलेक्ट्रॉनिक सर्किट पर, बाइनरी गेट्स पर, मशीन लैंग्वेज बाइनरी पर, प्रोग्रामिंग लैंग्वेज मशीन लैंग्वेज पर, एप्लिकेशन और ऑपरेटिंग सिस्टम प्रोग्रामिंग लैंग्वेज पर बनते हैं। प्रत्येक स्तर सन्निहित है, लेकिन उसके नीचे के स्तर से निर्धारित नहीं होता है, जिससे यह वर्णन की लैंग्वेज बन जाती है जो कुछ हद तक आत्मनिर्भर होती है। | ||
===डेटाबेस सिस्टम=== | ===डेटाबेस सिस्टम=== | ||
Line 203: | Line 204: | ||
स्तरित आर्किटेक्चर एप्लिकेशन की चिंताओं को स्टैक्ड समूहों (परतों) में विभाजित करता है। | स्तरित आर्किटेक्चर एप्लिकेशन की चिंताओं को स्टैक्ड समूहों (परतों) में विभाजित करता है। | ||
यह कंप्यूटर सॉफ्टवेयर, हार्डवेयर और संचार को डिजाइन करने में उपयोग की जाने वाली एक तकनीक है जिसमें सिस्टम या नेटवर्क | यह कंप्यूटर सॉफ्टवेयर, हार्डवेयर और संचार को डिजाइन करने में उपयोग की जाने वाली एक तकनीक है जिसमें सिस्टम या नेटवर्क कम्पोनेन्ट को परतों में अलग किया जाता है ताकि दूसरों को प्रभावित किए बिना एक परत में परिवर्तन किया जा सके। | ||
==यह भी देखें== | ==यह भी देखें== |
Revision as of 22:29, 11 July 2023
The essence of abstraction is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context.
सॉफ्टवेयर इंजीनियरिंग और कंप्यूटर विज्ञान में, अमूर्तन है:
- अधिक महत्व के विवरणों पर ध्यान केंद्रित करने के लिए वस्तुओं या प्रणालियों के अध्ययन में भौतिक, स्थानिक, या लौकिक विवरणों[2] या विशेषताओं को हटाने या सामान्य बनाने की प्रक्रिया;;[3] यह प्रकृति में सामान्यीकरण की प्रक्रिया के समान है;
- विभिन्न गैर-अमूर्त वस्तुओं या अध्ययन प्रणालियों की सामान्य विशेषताओं या विशेषताओं को प्रतिबिंबित करके अमूर्त अवधारणा वस्तुओं का निर्माण[3]- अमूर्तता की प्रक्रिया का परिणाम है।
सामान्य तौर पर, अमूर्तता, कंप्यूटर विज्ञान और सॉफ्टवेयर विकास में एक मौलिक अवधारणा है।[4] अमूर्तता की प्रक्रिया को मॉडलिंग के रूप में भी संदर्भित किया जा सकता है और यह सिद्धांत और डिजाइन की अवधारणाओं से निकटता से संबंधित है।[5] वास्तविकता के पहलुओं के सामान्यीकरण के अनुसार मॉडलों को अमूर्तता के प्रकार भी माना जा सकता है।
कंप्यूटर विज्ञान में अमूर्तता गणित में अमूर्तता से निकटता से संबंधित है क्योंकि उनका सामान्य ध्यान वस्तुओं के रूप में अमूर्तता के निर्माण पर है,[2] लेकिन यह अन्य क्षेत्रों अमूर्त (कला) में उपयोग की जाने वाली अमूर्तता की अन्य धारणाओं से भी संबंधित है।[3]
अमूर्तन वास्तविक दुनिया की वस्तुओं और प्रणालियों, कम्प्यूटेशनल प्रणालियों के नियमों या प्रोग्रामिंग लैंग्वेजओं के नियमों को भी संदर्भित कर सकता है जो अमूर्तता की विशेषताओं को ले जाते हैं या उनका उपयोग करते हैं, जैसे:
- कंप्यूटर प्रोग्राम के भीतर डेटा संरचनाओं के कामकाजी प्रतिनिधित्व से उपयोग को अलग करने के लिए डेटा अमूर्त करने के लिए डेटा प्रकारों का उपयोग;[6]
- प्रक्रियाओं, कार्यों या सबरूटीन्स (उपनेमिका) की अवधारणा जो फंक्शन में नियंत्रण प्रवाह को प्रयुक्त करने के एक विशिष्ट तरीके का प्रतिनिधित्व करती है;
- आमतौर पर एब्स्ट्रैक्शन नाम के नियम जो लैम्ब्डा कैलकुलस के विभिन्न संस्करणों में मुक्त चर और बाध्य चर का उपयोग करके व्यंजक (गणित) को सामान्यीकृत करते हैं;[7][8]
- लिस्प (प्रोग्रामिंग लैंग्वेज) में डेटा संरचनाओं और कार्यक्रमों के अमूर्त के रूप में एस- व्यंजक का उपयोग;[9]
- गैर-अमूर्त वर्गों से सामान्य व्यवहार को "अमूर्त वर्गों" में पुनर्गठित करने की प्रक्रिया, जैसा कि ऑब्जेक्ट-ओरिएंटेड सी ++ और जावा प्रोग्रामिंग लैंग्वेजओं में देखा जाता है, उप-वर्गों पर विरासत से अमूर्त तक का उपयोग किया जाता है।
तर्क
कंप्यूटिंग अधिकतर ठोस दुनिया से स्वतंत्र रूप से संचालित होती है। हार्डवेयर गणना का एक मॉडल लागू करता है जो दूसरों के साथ विनिमेय है।[10] सॉफ़्टवेयर को आर्किटेक्चर में स्ट्रक्चर्ड किया गया है ताकि मनुष्य एक समय में कुछ मुद्दों पर ध्यान केंद्रित करके विशाल सिस्टम बना सकें। ये आर्किटेक्चर अमूर्तता के विशिष्ट विकल्पों से बने होते हैं। ग्रीनस्पून का दसवां नियम इस बात पर एक सूत्र है कि इस तरह की वास्तुकला अपरिहार्य और जटिल दोनों है।
कंप्यूटिंग में अमूर्तता का एक केंद्रीय रूप लैंग्वेज अमूर्तता है: किसी प्रणाली के विशिष्ट पहलुओं को व्यक्त करने के लिए नई कल्पित लैंग्वेज (आर्टिफिशल लैंग्वेज) विकसित की जाती हैं। मॉडलिंग लैंग्वेजएं योजना बनाने में सहायता करती हैं। कंप्यूटर लैंग्वेजओं को कंप्यूटर से संसाधित किया जा सकता है। इस अमूर्त प्रक्रिया का एक उदाहरण मशीन लैंग्वेज से असेंबली लैंग्वेज और उच्च स्तरीय लैंग्वेज तक प्रोग्रामिंग लैंग्वेजओं का पीढ़ीगत विकास है। प्रत्येक चरण को अगले चरण के लिए एक सीढ़ी के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, स्क्रिप्टिंग लैंग्वेजओं और डोमेन-विशिष्ट प्रोग्रामिंग लैंग्वेजओं में लैंग्वेज का अमूर्तन जारी रहता है।
एक प्रोग्रामिंग लैंग्वेज के भीतर, कुछ विशेषताएं प्रोग्रामर को नए अमूर्त बनाने देती हैं। इनमें सबरूटीन्स, मॉड्यूल, पॉलीमॉरफिस्म (कंप्यूटर विज्ञान) और सॉफ्टवेयर कम्पोनेंट्स शामिल हैं। कुछ अन्य अमूर्तताएं जैसे सॉफ़्टवेयर डिज़ाइन पैटर्न और वास्तुशिल्प शैलियाँ अनुवादक के लिए अदृश्य रहती हैं और केवल सिस्टम के डिज़ाइन में ही काम करती हैं।
कुछ अमूर्त उन अवधारणाओं की सीमा को सीमित करने का प्रयास करते हैं जिनके बारे में एक प्रोग्रामर को जागरूक होने की आवश्यकता होती है, उन अमूर्तताओं को पूरी तरह से छिपाकर जिन पर वे बने होते हैं। सॉफ्टवेयर इंजीनियर और लेखक जोएल स्पॉल्स्की ने इन प्रयासों की यह दावा करते हुए आलोचना की है कि सभी अमूर्तताएँ लीक से हटकर हैं - कि वे कभी भी नीचे दिए गए विवरणों को पूरी तरह से छिपा नहीं सकते हैं;[11] हालाँकि, यह अमूर्तता की उपयोगिता को नकारता नहीं है।
कुछ अमूर्तताएं अन्य अमूर्तताओं के साथ अंतर-संचालित करने के लिए डिज़ाइन की गई हैं - उदाहरण के लिए, एक प्रोग्रामिंग लैंग्वेज में निचले स्तर की लैंग्वेज में कॉल करने के लिए एक फॉरेन फ़ंक्शन इंटरफ़ेस हो सकता है।
अमूर्त विशेषताएं
प्रोग्रामिंग लैंग्वेज
विभिन्न प्रोग्रामिंग लैंग्वेजएं, लैंग्वेज के लिए इच्छित अनुप्रयोगों के आधार पर, विभिन्न प्रकार के अमूर्तता प्रदान करती हैं। उदाहरण के लिए:
- ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेजओं जैसे C++, ऑब्जेक्ट पास्कल, या जावा (प्रोग्रामिंग लैंग्वेज) में, अमूर्तता की अवधारणा स्वयं एक घोषणात्मक कथन बन गई है - सिंटैक्स (प्रोग्रामिंग लैंग्वेजओं) का उपयोग करते हुए
function(parameters) = 0;
(सी++ में) या कीवर्ड (कंप्यूटर प्रोग्रामिंग)।abstract
[12] औरinterface
[13] (जावा में (प्रोग्रामिंग लैंग्वेज))। ऐसी घोषणा के बाद, यह प्रोग्रामर की जिम्मेदारी है कि वह घोषणा के ऑब्जेक्ट (कंप्यूटर विज्ञान) को इंस्टेंट करने के लिए एक क्लास (कंप्यूटर विज्ञान) को लागू करे। - कार्यात्मक प्रोग्रामिंग लैंग्वेजएं आमतौर पर कार्यों से संबंधित अमूर्तता प्रदर्शित करती हैं, जैसे लैम्ब्डा अमूर्तन (किसी शब्द को कुछ चर के फ़ंक्शन में बनाना) और उच्च-क्रम वाले फ़ंक्शन (पैरामीटर फ़ंक्शन होते हैं)।
- लिस्प प्रोग्रामिंग लैंग्वेज परिवार के आधुनिक सदस्य जैसे क्लोजर, स्कीम (प्रोग्रामिंग लैंग्वेज) और सामान्य लिस्प सिंटैक्टिक अमूर्तता की अनुमति देने के लिए मैक्रो (कंप्यूटर विज्ञान) सिंटैक्टिक मैक्रोज़ का समर्थन करते हैं। अन्य प्रोग्रामिंग लैंग्वेजओं जैसे स्काला (प्रोग्रामिंग लैंग्वेज) में भी मैक्रोज़, या बहुत समान मेटाप्रोग्रामिंग विशेषताएं हैं (उदाहरण के लिए, हास्केल (प्रोग्रामिंग लैंग्वेज) में टेम्पलेट हास्केल है, और ओकैमल में मेटाओकैमल है)। ये एक प्रोग्रामर को बॉयलरप्लेट कोड को समाप्त करने, बोरिंग फ़ंक्शन कॉल अनुक्रमों को दूर करने, नए नियंत्रण प्रवाह को लागू करने और डोमेन-विशिष्ट लैंग्वेज | डोमेन विशिष्ट लैंग्वेजओं (डीएसएल) को लागू करने की अनुमति दे सकते हैं, जो डोमेन-विशिष्ट अवधारणाओं को संक्षिप्त और सुरुचिपूर्ण तरीकों से व्यक्त करने की अनुमति देते हैं। . ये सभी, जब सही ढंग से उपयोग किए जाते हैं, तो इच्छित उद्देश्य को और अधिक स्पष्ट करके प्रोग्रामर की दक्षता और कोड की स्पष्टता दोनों में सुधार करते हैं। वाक्यात्मक अमूर्तन का एक परिणाम यह भी है कि किसी भी लिस्प बोली और वास्तव में लगभग किसी भी प्रोग्रामिंग लैंग्वेज को, सिद्धांत रूप में, किसी भी आधुनिक लिस्प में अधिक पारंपरिक प्रोग्रामिंग लैंग्वेजओं की तुलना में काफी कम (लेकिन ज्यादातर मामलों में अभी भी गैर-तुच्छ) प्रयास के साथ लागू किया जा सकता है। जैसे कि पायथन (प्रोग्रामिंग लैंग्वेज), सी (प्रोग्रामिंग लैंग्वेज) या जावा (प्रोग्रामिंग लैंग्वेज)।
स्पेसिफिकेशन विधियाँ
स्पेसिफिकेशन ने सॉफ्टवेयर सिस्टम को औपचारिक रूप से निर्दिष्ट करने के लिए विभिन्न तरीके विकसित किए हैं। कुछ ज्ञात विधियों में शामिल हैं:
- सार-मॉडल आधारित विधि (VDM, Z);
- बीजगणितीय तकनीकें (Larch, CLEAR, OBJ, ACT ONE, CASL);
- प्रक्रिया-आधारित तकनीकें (LOTOS, SDL, Estelle);
- ट्रेस-आधारित तकनीकें (SPECIAL, TAM);
- ज्ञान-आधारित तकनीकें (Refine, Gist)।
स्पेसिफिकेशन लैंग्वेज
स्पेसिफिकेशन लैंग्वेज आम तौर पर एक या दूसरे प्रकार के अमूर्त पर निर्भर करती हैं, क्योंकि स्पेसिफिकेशन को आम तौर पर किसी परियोजना में अंतिम कार्यान्वयन की तुलना में पहले (और अधिक अमूर्त स्तर पर) परिभाषित किया जाता है। उदाहरण के लिए, यूएमएल स्पेसिफिकेशन लैंग्वेज, अमूर्त वर्गों की परिलैंग्वेज की अनुमति देती है, जो एक वॉटरफॉल परियोजना में, परियोजना के वास्तुकला और स्पेसिफिकेशन चरण के दौरान अमूर्त रहते हैं।
नियंत्रण अमूर्तन
प्रोग्रामिंग लैंग्वेज अपने उपयोग के मुख्य उद्देश्यों में से एक के रूप में नियंत्रण अमूर्तता प्रदान करती हैं। कंप्यूटर मशीनें बहुत निम्न स्तर पर संचालन को समझती हैं जैसे कि कुछ बिट्स को मेमोरी के एक स्थान से दूसरे स्थान पर ले जाना और बिट्स के दो अनुक्रमों का योग उत्पन्न करना। प्रोग्रामिंग लैंग्वेज इसे उच्च स्तर पर करने की अनुमति देती हैं। उदाहरण के लिए, पास्कल (प्रोग्रामिंग लैंग्वेज) जैसी शैली में लिखे गए इस कथन पर विचार करें:
a := (1 + 2) * 5
एक इंसान के लिए, यह काफी सरल और स्पष्ट गणना लगती है ("एक प्लस दो तीन है, पांच गुना पंद्रह है")। हालाँकि, इस मूल्यांकन को करने के लिए आवश्यक निम्न-स्तरीय कदम, और मान "15" लौटाना, और फिर उस मान को वेरिएबल "ए" पर निर्दिष्ट करना, वास्तव में काफी सूक्ष्म और जटिल हैं। मानों को बाइनरी प्रतिनिधित्व में परिवर्तित करने की आवश्यकता होती है (अक्सर किसी की सोच से कहीं अधिक जटिल कार्य) और गणनाओं को (संकलक या दुभाषिया द्वारा) असेंबली निर्देशों में विघटित किया जाता है (फिर से, जो प्रोग्रामर के लिए बहुत कम सहज होते हैं: संचालन जैसे एक बाइनरी रजिस्टर को बाईं ओर स्थानांतरित करना, या एक रजिस्टर की सामग्री के बाइनरी पूरक को दूसरे में जोड़ना, बिल्कुल वैसा नहीं है जैसा मनुष्य जोड़ या गुणा के अमूर्त अंकगणितीय संचालन के बारे में सोचते हैं)। अंत में, "a" लेबल वाले वेरिएबल को "15" का परिणामी मान निर्दिष्ट करना, ताकि "a" का उपयोग बाद में किया जा सके, इसमें वेरिएबल के लेबल और भौतिक में परिणामी स्थान को देखने के अतिरिक्त 'पर्दे के पीछे' चरण शामिल होते हैं। या वर्चुअल मेमोरी, उस मेमोरी स्थान पर "15" के बाइनरी प्रतिनिधित्व को संग्रहीत करना, आदि।
नियंत्रण अमूर्तता के बिना, एक प्रोग्रामर को हर बार सभी रजिस्टर/बाइनरी-स्तरीय चरणों को निर्दिष्ट करने की आवश्यकता होगी, जब वे बस कुछ संख्याओं को जोड़ना या गुणा करना चाहते थे और परिणाम को एक चर में निर्दिष्ट करना चाहते थे। प्रयास के इस प्रकार के दोहराव के दो गंभीर नकारात्मक परिणाम होते हैं:
- यह प्रोग्रामर को हर बार समान ऑपरेशन की आवश्यकता होने पर लगातार सामान्य कार्यों को दोहराने के लिए मजबूर करता है
- यह प्रोग्रामर को विशेष हार्डवेयर और निर्देश सेट के लिए प्रोग्राम करने के लिए बाध्य करता है
स्ट्रक्चर्ड प्रोग्रामिंग
स्ट्रक्चर्ड प्रोग्रामिंग में जटिल प्रोग्राम कार्यों को स्पष्ट प्रवाह-नियंत्रण और कम्पोनेन्ट के बीच इंटरफेस के साथ छोटे टुकड़ों में विभाजित करना शामिल है, जिससे साइड-इफेक्ट्स की जटिलता क्षमता में कमी आती है।
एक सरल कार्यक्रम में, इसका उद्देश्य यह सुनिश्चित करना हो सकता है कि लूप में एकल या स्पष्ट निकास बिंदु हों और (जहां संभव हो) कार्यों और प्रक्रियाओं से एकल निकास बिंदु हों।
एक बड़ी प्रणाली में, इसमें जटिल कार्यों को कई अलग-अलग मॉड्यूल में विभाजित करना शामिल हो सकता है। एक ऐसी प्रणाली पर विचार करें जो जहाजों और तटीय कार्यालयों पर पेरोल को संभालती है:
- सबसे ऊपरी स्तर पर विशिष्ट अंतिम-उपयोगकर्ता संचालन का एक मेनू हो सकता है।
- उसके भीतर कर्मचारियों के हस्ताक्षर करने और बंद करने या चेक प्रिंट करने जैसे कार्यों के लिए स्टैंडअलोन निष्पादन योग्य या लाइब्रेरी हो सकती हैं।
- उन स्टैंडअलोन कम्पोनेन्ट में से प्रत्येक के भीतर कई अलग-अलग स्रोत फ़ाइलें हो सकती हैं, प्रत्येक में समस्या के एक हिस्से को संभालने के लिए प्रोग्राम कोड होता है, प्रोग्राम के अन्य हिस्सों के लिए केवल चयनित इंटरफ़ेस उपलब्ध होते हैं। प्रोग्राम पर एक साइन में प्रत्येक डेटा एंट्री स्क्रीन और डेटाबेस इंटरफ़ेस के लिए स्रोत फ़ाइलें हो सकती हैं (जो स्वयं एक स्टैंडअलोन थर्ड पार्टी लाइब्रेरी या लाइब्रेरी रूटीन का एक स्थिर रूप से जुड़ा हुआ सेट हो सकता है)।
- या तो डेटाबेस या पेरोल एप्लिकेशन को जहाज और तट के बीच डेटा के आदान-प्रदान की प्रक्रिया शुरू करनी होगी, और उस डेटा ट्रांसफर कार्य में अक्सर कई अन्य घटक शामिल होंगे।
ये परतें एक घटक के कार्यान्वयन विवरण और उसके मिश्रित आंतरिक तरीकों को दूसरों से अलग करने का प्रभाव उत्पन्न करती हैं। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग इस अवधारणा को अपनाती है और इसका विस्तार करती है।
डेटा अमूर्त
डेटा अमूर्तन डेटा प्रकार के अमूर्त गुणों और इसके कार्यान्वयन के ठोस विवरण के बीच स्पष्ट अलगाव को लागू करता है। अमूर्त गुण वे हैं जो क्लाइंट कोड को दिखाई देते हैं जो डेटा प्रकार का उपयोग करते हैं - डेटा प्रकार के लिए इंटरफ़ेस - जबकि ठोस कार्यान्वयन पूरी तरह से निजी रखा जाता है, और वास्तव में बदल सकता है, उदाहरण के लिए समय के साथ दक्षता में सुधार शामिल करना। विचार यह है कि ऐसे परिवर्तनों का क्लाइंट कोड पर कोई प्रभाव नहीं पड़ता है, क्योंकि उनमें अमूर्त व्यवहार में कोई अंतर नहीं होता है।
उदाहरण के लिए, कोई एक अमूर्त डेटा प्रकार को परिभाषित कर सकता है जिसे लुकअप टेबल कहा जाता है जो विशिष्ट रूप से मानों के साथ कुंजियों को जोड़ता है, और जिसमें मानों को उनकी संबंधित कुंजियों को निर्दिष्ट करके पुनर्प्राप्त किया जा सकता है। ऐसी लुकअप टेबल को विभिन्न तरीकों से कार्यान्वित किया जा सकता है: एक हैश टेबल, एक बाइनरी सर्च ट्री, या यहां तक कि (कुंजी: मान) जोड़े की एक सरल रैखिक सूची (कंप्यूटिंग) के रूप में। जहां तक क्लाइंट कोड का सवाल है, प्रत्येक मामले में प्रकार के अमूर्त गुण समान हैं।
यह सब सबसे पहले इंटरफ़ेस का विवरण प्राप्त करने पर निर्भर करता है, क्योंकि वहां कोई भी बदलाव क्लाइंट कोड पर बड़ा प्रभाव डाल सकता है। इसे देखने का एक तरीका: इंटरफ़ेस डेटा प्रकार और क्लाइंट कोड के बीच सहमत व्यवहार पर एक अनुबंध बनाता है; अनुबंध में जो कुछ भी नहीं लिखा गया है, वह बिना किसी सूचना के परिवर्तन के अधीन है।
मैनुअल डेटा अमूर्त
जबकि अधिकांश डेटा अमूर्त कंप्यूटर विज्ञान और स्वचालन के माध्यम से होता है, ऐसे समय होते हैं जब यह प्रक्रिया मैन्युअल रूप से और प्रोग्रामिंग हस्तक्षेप के बिना की जाती है। इसे समझने का एक तरीका साहित्य की व्यवस्थित समीक्षा करने की प्रक्रिया के भीतर डेटा अमूर्तन के माध्यम से है। इस पद्धति में, मेटा-विश्लेषण करते समय डेटा को एक या कई अमूर्तकर्ताओं द्वारा अमूर्त किया जाता है, जिसमें दोहरे डेटा अमूर्तन के माध्यम से त्रुटियों को कम किया जाता है, जिसके बाद स्वतंत्र जाँच की जाती है, जिसे निर्णय के रूप में जाना जाता है।[14]
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में अमूर्तन
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सिद्धांत में, अमूर्तता में उन वस्तुओं को परिभाषित करने की सुविधा शामिल होती है जो अमूर्त अभिनेताओं का प्रतिनिधित्व करती हैं जो काम कर सकते हैं, रिपोर्ट कर सकते हैं और अपनी स्थिति बदल सकते हैं, और सिस्टम में अन्य वस्तुओं के साथ संचार कर सकते हैं। एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) शब्द राज्य (कंप्यूटर विज्ञान) विवरणों को छिपाने को संदर्भित करता है, लेकिन डेटा के साथ व्यवहार को सबसे मजबूती से जोड़ने के लिए पहले की प्रोग्रामिंग लैंग्वेजओं से डेटा प्रकार की अवधारणा का विस्तार करता है, और विभिन्न डेटा प्रकारों के इंटरैक्ट करने के तरीके को मानकीकृत करना, अमूर्तन की शुरुआत है। जब अमूर्तता परिभाषित कार्यों में आगे बढ़ती है, जिससे विभिन्न प्रकार की वस्तुओं को प्रतिस्थापित किया जा सकता है, तो इसे बहुरूपता (कंप्यूटर विज्ञान) कहा जाता है। जब यह विपरीत दिशा में आगे बढ़ता है, प्रकारों या वर्गों के अंदर, रिश्तों के एक जटिल सेट को सरल बनाने के लिए उन्हें स्ट्रक्चर्ड करता है, तो इसे प्रतिनिधिमंडल (वस्तु-उन्मुख प्रोग्रामिंग) या इनहेरिटेंस (कंप्यूटर विज्ञान) कहा जाता है।
विभिन्न ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेजएं अमूर्तता के लिए समान सुविधाएं प्रदान करती हैं, सभी ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता (कंप्यूटर विज्ञान) की एक सामान्य रणनीति का समर्थन करने के लिए, जिसमें समान या समान भूमिका में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में कॉन्फ़िगरेशन प्रकार का दूसरे के लिए प्रतिस्थापन शामिल है। . यद्यपि आम तौर पर समर्थित नहीं है, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग या छवि या पैकेज में एक कॉन्फ़िगरेशन संकलन-समय, लिंक समय , या लोड होने का समय पर इनमें से कई नामों को पूर्व निर्धारित कर सकता है। इससे रन टाइम (प्रोग्राम जीवनचक्र चरण)|रन-टाइम पर बदलने के लिए ऐसी नाम बंधन ही बचेगी।
उदाहरण के लिए, सामान्य लिस्प ऑब्जेक्ट सिस्टम या सेल्फ (प्रोग्रामिंग लैंग्वेज)ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग टाइप करें क्लास-इंस्टेंस भेद की कम सुविधा और बहुरूपता के लिए प्रतिनिधिमंडल का अधिक उपयोग करता है। [[स्वयं (प्रोग्रामिंग लैंग्वेज)]] की साझा कार्यात्मक विरासत के साथ बेहतर ढंग से फिट होने के लिए व्यक्तिगत वस्तुओं और कार्यों को अधिक लचीले ढंग से अमूर्त किया जाता है।
C++ एक और चरम का उदाहरण देता है: यह सामान्य प्रोग्रामिंग और विधि ओवरलोडिंग और संकलन-समय पर अन्य स्थैतिक बाइंडिंग पर बहुत अधिक निर्भर करता है, जिसके बदले में कुछ लचीलेपन की समस्याएं होती हैं।
यद्यपि ये उदाहरण समान अमूर्तता को प्राप्त करने के लिए वैकल्पिक रणनीतियों की पेशकश करते हैं, लेकिन वे कोड में अमूर्त संज्ञाओं का समर्थन करने की आवश्यकता को मौलिक रूप से नहीं बदलते हैं - सभी प्रोग्रामिंग क्रियाओं को कार्यों के रूप में, संज्ञाओं को डेटा संरचनाओं के रूप में, और या तो प्रक्रियाओं के रूप में अमूर्त करने की क्षमता पर निर्भर करती हैं।
उदाहरण के लिए एक नमूना जावा (प्रोग्रामिंग लैंग्वेज) टुकड़े पर विचार करें जो कुछ सामान्य खेत जानवरों को उनकी भूख और भोजन के सरल पहलुओं को मॉडल करने के लिए उपयुक्त अमूर्त स्तर पर प्रस्तुत करता है। यह एक को परिभाषित करता है Animal
जानवर की स्थिति और उसके कार्यों दोनों का प्रतिनिधित्व करने वाला वर्ग:
public class Animal extends LivingThing
{
private Location loc;
private double energyReserves;
public boolean isHungry() {
return energyReserves < 2.5;
}
public void eat(Food food) {
// Consume food
energyReserves += food.getCalories();
}
public void moveTo(Location location) {
// Move to new location
this.loc = location;
}
}
उपरोक्त परिलैंग्वेज के साथ, कोई भी प्रकार की वस्तुएं बना सकता है Animal और उनकी विधियों को इस प्रकार कॉल करें:
thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
theCow.eat(grass);
}
theCow.moveTo(theBarn);
उपरोक्त उदाहरण में, classAnimal
एक वास्तविक जानवर के स्थान पर प्रयुक्त एक अमूर्तन है,LivingThing
का एक और अमूर्तन (इस मामले में एक सामान्यीकरण) हैAnimal
.
यदि किसी को जानवरों के अधिक विभेदित पदानुक्रम की आवश्यकता है - मान लीजिए, जो लोग अपने जीवन के अंत में मांस के अलावा कुछ भी नहीं देते हैं, उनसे दूध प्रदान करने वालों को अलग करना है - यह अमूर्तता का एक मध्यवर्ती स्तर है, शायद डेयरीएनिमल (गाय, बकरी) जो ऐसा करेगा अच्छा दूध देने के लिए उपयुक्त खाद्य पदार्थ खाएं, और मीटएनिमल (सूअर, स्टीयर) जो सर्वोत्तम मांस-गुणवत्ता देने के लिए खाद्य पदार्थ खाएंगे।
इस तरह के एक अमूर्तन से एप्लिकेशन कोडर के लिए भोजन के प्रकार को निर्दिष्ट करने की आवश्यकता समाप्त हो सकती है, ताकि वे इसके बजाय भोजन शेड्यूल पर ध्यान केंद्रित कर सकें। दोनों वर्गों को इनहेरिटेंस (कंप्यूटर विज्ञान) का उपयोग करके या अकेले खड़ा किया जा सकता है, और प्रोग्रामर दो प्रकारों के बीच बहुरूपता (कंप्यूटर विज्ञान) की अलग-अलग डिग्री को परिभाषित कर सकता है। ये सुविधाएं लैंग्वेजओं के बीच काफी भिन्न होती हैं, लेकिन सामान्य तौर पर प्रत्येक लैंग्वेज कुछ भी हासिल कर सकती है जो किसी अन्य के साथ संभव है। बड़ी संख्या में ऑपरेशन ओवरलोड, डेटा प्रकार के आधार पर डेटा, संकलन-समय पर वंशानुक्रम की किसी भी डिग्री या बहुरूपता प्राप्त करने के अन्य साधनों के समान प्रभाव डाल सकते हैं। क्लास नोटेशन बस एक कोडर की सुविधा है।
वस्तु-उन्मुख डिज़ाइन
क्या अमूर्त करना है और क्या कोडर के नियंत्रण में रखना है, इसके बारे में निर्णय ऑब्जेक्ट-ओरिएंटेड डिज़ाइन और डोमेन विश्लेषण की प्रमुख चिंता बन जाते हैं - वास्तव में वास्तविक दुनिया में प्रासंगिक संबंधों का निर्धारण करना ऑब्जेक्ट-ओरिएंटेड विश्लेषण और डिज़ाइन की चिंता है|ऑब्जेक्ट- उन्मुख विश्लेषण या विरासत विश्लेषण।
सामान्य तौर पर, उपयुक्त अमूर्तता निर्धारित करने के लिए, किसी को दायरे (डोमेन विश्लेषण) के बारे में कई छोटे निर्णय लेने चाहिए, यह निर्धारित करना चाहिए कि उसे किन अन्य प्रणालियों (विरासत विश्लेषण) के साथ सहयोग करना चाहिए, फिर एक विस्तृत वस्तु-उन्मुख विश्लेषण करना चाहिए जो परियोजना समय और बजट के भीतर व्यक्त किया जाता है वस्तु-उन्मुख डिज़ाइन के रूप में बाधाएँ। हमारे सरल उदाहरण में, डोमेन बाड़ा है, जीवित सूअर और गायें और उनके खाने की आदतें विरासत की बाधाएं हैं, विस्तृत विश्लेषण यह है कि कोडर्स के पास जानवरों को खिलाने के लिए लचीलापन होना चाहिए जो उपलब्ध है और इस प्रकार कोड करने का कोई कारण नहीं है कक्षा में ही भोजन का प्रकार, और डिज़ाइन एक एकल सरल पशु वर्ग है जिसमें सूअर और गाय समान कार्य वाले उदाहरण हैं। डेयरीएनिमल को अलग करने का निर्णय विस्तृत विश्लेषण को बदल देगा लेकिन डोमेन और विरासत विश्लेषण अपरिवर्तित रहेगा - इस प्रकार यह पूरी तरह से प्रोग्रामर के नियंत्रण में है, और इसे डोमेन या विरासत में अमूर्त से अलग ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में एक अमूर्त कहा जाता है। विश्लेषण।
विचार
प्रोग्रामिंग लैंग्वेजओं, औपचारिक तरीकों या अमूर्त व्याख्या के औपचारिक शब्दार्थ पर चर्चा करते समय, अमूर्तता, देखे गए प्रोग्राम व्यवहारों की कम विस्तृत, लेकिन सुरक्षित परिलैंग्वेज पर विचार करने के कार्य को संदर्भित करती है। उदाहरण के लिए, कोई निष्पादन के सभी मध्यवर्ती चरणों पर विचार करने के बजाय केवल प्रोग्राम निष्पादन के अंतिम परिणाम को देख सकता है। अमूर्तन को निष्पादन के एक ठोस (अधिक सटीक) मॉडल के रूप में परिभाषित किया गया है।
किसी संपत्ति के संबंध में अमूर्तता सटीक या विश्वसनीय हो सकती है यदि कोई व्यक्ति संपत्ति के बारे में किसी प्रश्न का उत्तर ठोस या अमूर्त मॉडल पर समान रूप से अच्छी तरह से दे सकता है। उदाहरण के लिए, यदि कोई जानना चाहता है कि केवल पूर्णांक +, -, × वाले गणितीय व्यंजक के मूल्यांकन का परिणाम मॉड्यूलर अंकगणित एन के बराबर है, तो उसे केवल सभी ऑपरेशन मॉड्यूलो एन करने की जरूरत है। (इस अमूर्तन का एक परिचित रूप नौ को बाहर निकालना है)।
हालाँकि, सार-संक्षेप, हालांकि जरूरी नहीं कि सटीक हों, ठोस होने चाहिए। अर्थात्, उनसे ठोस उत्तर प्राप्त करना संभव होना चाहिए - भले ही अमूर्तता केवल अनिर्णीत समस्या का परिणाम दे सकती है। उदाहरण के लिए, किसी कक्षा में छात्रों को उनकी न्यूनतम और अधिकतम आयु से अलग किया जा सकता है; यदि कोई पूछता है कि क्या कोई निश्चित व्यक्ति उस वर्ग का है, तो वह बस उस व्यक्ति की उम्र की तुलना न्यूनतम और अधिकतम उम्र से कर सकता है; यदि उसकी आयु सीमा से बाहर है, तो कोई भी सुरक्षित रूप से उत्तर दे सकता है कि वह व्यक्ति उस वर्ग से संबंधित नहीं है; यदि ऐसा नहीं है, तो कोई केवल यही उत्तर दे सकता है कि मैं नहीं जानता।
किसी प्रोग्रामिंग लैंग्वेज में शामिल अमूर्तता का स्तर इसकी समग्र प्रयोज्यता को प्रभावित कर सकता है। संज्ञानात्मक आयाम ढांचे में औपचारिकता में अमूर्त ढाल की अवधारणा शामिल है। यह ढांचा एक प्रोग्रामिंग लैंग्वेज के डिजाइनर को अमूर्तता और डिजाइन की अन्य विशेषताओं के बीच व्यापार-बंद का अध्ययन करने की अनुमति देता है, और अमूर्तता में परिवर्तन लैंग्वेज की उपयोगिता को कैसे प्रभावित करते हैं।
कंप्यूटर प्रोग्राम के साथ व्यवहार करते समय सार-संक्षेप उपयोगी साबित हो सकते हैं, क्योंकि कंप्यूटर प्रोग्राम के गैर-तुच्छ गुण अनिवार्य रूप से अनिर्णीत समस्या हैं (राइस का प्रमेय देखें)। परिणामस्वरूप, कंप्यूटर प्रोग्राम के व्यवहार के बारे में जानकारी प्राप्त करने के लिए स्वचालित तरीकों को या तो समाप्ति (कुछ अवसरों पर, वे विफल हो सकते हैं, क्रैश हो सकते हैं या कभी परिणाम नहीं दे सकते हैं), सुदृढ़ता (वे गलत जानकारी प्रदान कर सकते हैं), या सटीकता ( वे कुछ प्रश्नों का उत्तर दे सकते हैं जिन्हें मैं नहीं जानता)।
अमूर्तन, अमूर्त व्याख्या की मूल अवधारणा है। मॉडल जाँच आम तौर पर अध्ययन किए गए सिस्टम के अमूर्त संस्करणों पर होती है।
अमूर्तता का स्तर
कंप्यूटर विज्ञान आमतौर पर अमूर्तता के स्तर (या, कम सामान्यतः, परतें) प्रस्तुत करता है, जिसमें प्रत्येक स्तर एक ही जानकारी और प्रक्रियाओं के एक अलग मॉडल का प्रतिनिधित्व करता है, लेकिन अलग-अलग मात्रा में विवरण के साथ। प्रत्येक स्तर व्यंजक की एक प्रणाली का उपयोग करता है जिसमें वस्तुओं और रचनाओं का एक अनूठा सेट शामिल होता है जो केवल एक विशेष डोमेन पर लागू होता है। [15] प्रत्येक अपेक्षाकृत अमूर्त, उच्च स्तर अपेक्षाकृत ठोस, निचले स्तर पर निर्मित होता है, जो तेजी से दानेदार प्रतिनिधित्व प्रदान करता है। उदाहरण के लिए, गेट्स इलेक्ट्रॉनिक सर्किट पर, बाइनरी गेट्स पर, मशीन लैंग्वेज बाइनरी पर, प्रोग्रामिंग लैंग्वेज मशीन लैंग्वेज पर, एप्लिकेशन और ऑपरेटिंग सिस्टम प्रोग्रामिंग लैंग्वेज पर बनते हैं। प्रत्येक स्तर सन्निहित है, लेकिन उसके नीचे के स्तर से निर्धारित नहीं होता है, जिससे यह वर्णन की लैंग्वेज बन जाती है जो कुछ हद तक आत्मनिर्भर होती है।
डेटाबेस सिस्टम
चूँकि डेटाबेस सिस्टम के कई उपयोगकर्ताओं के पास कंप्यूटर डेटा-संरचनाओं के साथ गहराई से परिचित होने की कमी है, डेटाबेस डेवलपर्स अक्सर निम्नलिखित स्तरों के माध्यम से जटिलता को छिपाते हैं:
भौतिक स्तर: अमूर्तता का निम्नतम स्तर बताता है कि कोई सिस्टम वास्तव में डेटा कैसे संग्रहीत करता है। भौतिक स्तर जटिल निम्न-स्तरीय डेटा संरचनाओं का विस्तार से वर्णन करता है।
तार्किक स्तर: अमूर्तता का अगला उच्च स्तर बताता है कि डेटाबेस क्या डेटा संग्रहीत करता है, और उन डेटा के बीच क्या संबंध मौजूद हैं। इस प्रकार तार्किक स्तर अपेक्षाकृत सरल संरचनाओं की एक छोटी संख्या के संदर्भ में संपूर्ण डेटाबेस का वर्णन करता है। यद्यपि तार्किक स्तर पर सरल संरचनाओं के कार्यान्वयन में जटिल भौतिक स्तर की संरचनाएं शामिल हो सकती हैं, तार्किक स्तर के उपयोगकर्ता को इस जटिलता के बारे में जागरूक होने की आवश्यकता नहीं है। इसे भौतिक डेटा स्वतंत्रता के रूप में जाना जाता है। डेटाबेस प्रशासक, जिन्हें यह तय करना होता है कि डेटाबेस में कौन सी जानकारी रखनी है, अमूर्तता के तार्किक स्तर का उपयोग करते हैं।
दृश्य स्तर: अमूर्तता का उच्चतम स्तर संपूर्ण डेटाबेस के केवल एक भाग का वर्णन करता है। भले ही तार्किक स्तर सरल संरचनाओं का उपयोग करता है, बड़े डेटाबेस में संग्रहीत जानकारी की विविधता के कारण जटिलता बनी रहती है। डेटाबेस सिस्टम के कई उपयोगकर्ताओं को इस सारी जानकारी की आवश्यकता नहीं होती है; इसके बजाय, उन्हें डेटाबेस के केवल एक हिस्से तक पहुंचने की आवश्यकता है। सिस्टम के साथ उनकी बातचीत को सरल बनाने के लिए अमूर्तता का दृश्य स्तर मौजूद है। सिस्टम एक ही डेटाबेस के लिए कई दृश्य (डेटाबेस) प्रदान कर सकता है।
स्तरित वास्तुकला
अमूर्तता के विभिन्न स्तरों का डिज़ाइन प्रदान करने की क्षमता
- डिज़ाइन को काफी सरल बनाएं
- विभिन्न भूमिका निभाने वालों को अमूर्तता के विभिन्न स्तरों पर प्रभावी ढंग से काम करने में सक्षम बनाना
- सॉफ़्टवेयर कलाकृतियों की पोर्टेबिलिटी का समर्थन करें (आदर्श रूप से मॉडल-आधारित)
सिस्टम डिज़ाइन और व्यवसाय प्रक्रिया मॉडलिंग दोनों इसका उपयोग कर सकते हैं। कुछ सॉफ्टवेयर मॉडलिंग विशेष रूप से ऐसे डिज़ाइन तैयार करते हैं जिनमें अमूर्तता के विभिन्न स्तर होते हैं।
स्तरित आर्किटेक्चर एप्लिकेशन की चिंताओं को स्टैक्ड समूहों (परतों) में विभाजित करता है। यह कंप्यूटर सॉफ्टवेयर, हार्डवेयर और संचार को डिजाइन करने में उपयोग की जाने वाली एक तकनीक है जिसमें सिस्टम या नेटवर्क कम्पोनेन्ट को परतों में अलग किया जाता है ताकि दूसरों को प्रभावित किए बिना एक परत में परिवर्तन किया जा सके।
यह भी देखें
- अमूर्त सिद्धांत (कंप्यूटर प्रोग्रामिंग)
- अमूर्तता में एक खतरे के विरोधी पैटर्न के लिए अमूर्त व्युत्क्रम
- डेटा के एक सेट के सार विवरण के लिए सार डेटा प्रकार
- कम्प्यूटेशनल प्रक्रिया के सार विवरण के लिए कलन विधि
- किसी पद को किसी चर के फ़ंक्शन में बनाने के लिए ब्रैकेट अमूर्तन
- डेटा का उपयोग करने वाली प्रक्रियाओं से स्वतंत्र संरचना के लिए मॉडलिंग की दिनांक
- अमूर्तन के लिए एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) जो कार्यान्वयन विवरण छुपाता है
- अमूर्तता के स्थान में एक (द?) इष्टतम बिंदु के बारे में एक सूत्र के लिए ग्रीनस्पून का दसवां नियम
- अमूर्तन के लिए उच्च-क्रम फ़ंक्शन जहां फ़ंक्शन अन्य कार्यों का उत्पादन या उपभोग करते हैं
- किसी शब्द को किसी चर के फ़ंक्शन में बनाने के लिए लैम्ब्डा एब्स्ट्रैक्शन
- अमूर्तों की सूची (कंप्यूटर विज्ञान)
- कंप्यूटिंग में अमूर्तता के विपरीत के लिए कार्यक्रम परिशोधन
- पूर्णांक (कंप्यूटर विज्ञान)
- अनुमानी (कंप्यूटर विज्ञान)
संदर्भ
- ↑ Guttag, John V. (18 January 2013). Introduction to Computation and Programming Using Python (Spring 2013 ed.). Cambridge, Massachusetts: The MIT Press. ISBN 9780262519632.
- ↑ 2.0 2.1 Colburn, Timothy; Shute, Gary (5 June 2007). "कंप्यूटर विज्ञान में अमूर्तन". Minds and Machines (in English). 17 (2): 169–184. doi:10.1007/s11023-007-9061-7. ISSN 0924-6495. S2CID 5927969.
- ↑ 3.0 3.1 3.2 Kramer, Jeff (1 April 2007). "Is abstraction the key to computing?". Communications of the ACM. 50 (4): 36–42. doi:10.1145/1232743.1232745. ISSN 0001-0782. S2CID 12481509.
- ↑ Ben-Ari, Mordechai (1 March 1998). "कंप्यूटर विज्ञान शिक्षा में रचनावाद". ACM SIGCSE Bulletin. 30 (1): 257, 257–261. doi:10.1145/274790.274308. ISSN 0097-8418.
- ↑ Comer, D. E.; Gries, David; Mulder, Michael C.; Tucker, Allen; Turner, A. Joe; Young, Paul R. /Denning (1 January 1989). "एक अनुशासन के रूप में कंप्यूटिंग". Communications of the ACM. 32 (1): 9–23. doi:10.1145/63238.63239. ISSN 0001-0782. S2CID 723103.
- ↑ Liskov, Barbara (1 May 1988). "Keynote address – data abstraction and hierarchy". ACM SIGPLAN Notices. ACM. 23: 17–34. doi:10.1145/62138.62141. ISBN 0897912667. S2CID 14219043.
- ↑ Barendregt, Hendrik Pieter (1984). The lambda calculus : its syntax and semantics (Revised ed.). Amsterdam: North-Holland. ISBN 0444867481. OCLC 10559084.
- ↑ Barendregt, Hendrik Pieter (2013). प्रकार के साथ लैम्ब्डा कैलकुलस. Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic. Cambridge, UK: Cambridge University Press. ISBN 9780521766142. OCLC 852197712.
- ↑ Newell, Allen; Simon, Herbert A. (1 January 2007). Computer science as empirical inquiry: symbols and search. ACM. p. 1975. doi:10.1145/1283920.1283930. ISBN 9781450310499.
- ↑ Floridi, Luciano (September 2008). "अमूर्तन के स्तर की विधि". Minds and Machines (in English). 18 (3): 303–329. doi:10.1007/s11023-008-9113-7. hdl:2299/2998. ISSN 0924-6495. S2CID 7522925.
- ↑ Spolsky, Joel. "लीकी एब्स्ट्रैक्शन का नियम".
- ↑ "सार विधियाँ और कक्षाएं". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.
- ↑ "एक इंटरफ़ेस को एक प्रकार के रूप में उपयोग करना". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.
- ↑ E, Jian‐Yu; Saldanha, Ian J.; Canner, Joseph; Schmid, Christopher H.; Le, Jimmy T.; Li, Tianjing (2020). "व्यवस्थित समीक्षाओं में डेटा को अमूर्त करने में त्रुटियों को कम करने में डेटा अमूर्त के अनुभव के बजाय निर्णय अधिक मायने रखता है". Research Synthesis Methods (in English). 11 (3): 354–362. doi:10.1002/jrsm.1396. ISSN 1759-2879. PMID 31955502. S2CID 210829764.
- ↑ Luciano Floridi, Levellism and the Method of Abstraction IEG – Research Report 22.11.04
अग्रिम पठन
- Harold Abelson; Gerald Jay Sussman; Julie Sussman (25 July 1996). Structure and Interpretation of Computer Programs (2 ed.). MIT Press. ISBN 978-0-262-01153-2. Archived from the original on 26 February 2009. Retrieved 22 June 2012.
- Spolsky, Joel (11 November 2002). "The Law of Leaky Abstractions". Joel on Software.
- Abstraction/information hiding – CS211 course, Cornell University.
- Eric S. Roberts (1997). Programming Abstractions in C A Second Course in Computer Science.
- Palermo, Jeffrey (29 July 2008). "The Onion Architecture". Jeffrey Palermo.
- Vishkin, Uzi (January 2011). "Using simple abstraction to reinvent computing for parallelism". Communications of the ACM. 54 (1): 75–85. doi:10.1145/1866739.1866757.
बाहरी संबंध
- SimArch example of layered architecture for distributed simulation systems.