अमूर्त सिद्धांत (कंप्यूटर प्रोग्रामिंग): Difference between revisions
No edit summary |
No edit summary |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
[[सॉफ्टवेयर इंजीनियरिंग]] और [[प्रोग्रामिंग भाषा सिद्धांत]] में, अमूर्त सिद्धांत (या अमूर्त का सिद्धांत) एक | [[सॉफ्टवेयर इंजीनियरिंग]] और [[प्रोग्रामिंग भाषा सिद्धांत]] में, अमूर्त सिद्धांत (या अमूर्त का सिद्धांत) एक मूलभूत सिद्धांत है जिसका उद्देश्य अमूर्त (कंप्यूटर विज्ञान) का उपयोग करके किसी प्रोग्राम में जानकारी के दोहराव को कम करना है (सामान्यतः [[कोड दोहराव]] पर जोर देने के साथ) )एस प्रोग्रामिंग भाषा या [[सॉफ़्टवेयर लाइब्रेरी]] द्वारा प्रदान किया जाता है सिद्धांत को कभी-कभी प्रोग्रामर के लिए एक अनुशंसा के रूप में कहा जाता है, किंतु कभी-कभी इसे प्रोग्रामिंग भाषा की आवश्यकता के रूप में भी कहा जाता है, यह मानते हुए कि यह स्व-समझ में आता है कि क्यों अमूर्त का उपयोग करना वांछनीय है। सिद्धांत की उत्पत्ति अनिश्चित है;इसे कई बार कभी-कभी थोड़े बदलावों के साथ एक अलग नाम के तहत पुनर्निर्मित किया गया है। | ||
जब प्रोग्रामर की | जब प्रोग्रामर की पक्षसमर्थन के रूप में पढ़ा जाता है, तो अमूर्त सिद्धांत को स्वयं को न दोहराने (ड्राई ) सिद्धांत के रूप में सामान्यीकृत किया जा सकता है, जो सामान्य रूप से जानकारी के दोहराव से बचने की पक्षसमर्थन करता है, और सॉफ्टवेयर विकास प्रक्रिया में सम्मिलित मानव प्रयास के दोहराव से भी बचाता है। . | ||
== सिद्धांत == | == सिद्धांत == | ||
प्रोग्रामर को एक अनुशंसा के रूप में, बेंजामिन सी | प्रोग्रामर को एक अनुशंसा के रूप में, बेंजामिन सी पियर्स द्वारा [[ प्रकार और प्रोग्रामिंग भाषाएँ |प्रकार और प्रोग्रामिंग भाषाएँ]] (2002) में इसके निर्माण में, अमूर्त सिद्धांत (मूल में जोर) पढ़ता है:<ref>{{cite book|last=Pierce|first=Benjamin|title=प्रकार और प्रोग्रामिंग भाषाएँ|publisher=MIT Press|year=2002|isbn=0-262-16209-1|page=339}}</ref> | ||
{{cquote| | {{cquote|किसी प्रोग्राम में प्रत्येक महत्वपूर्ण कार्यक्षमता को स्रोत कोड में केवल एक ही स्थान पर प्रयुक्त किया जाना चाहिए। जहां समान कार्य कोड के अलग-अलग टुकड़ों द्वारा किए जाते हैं, वहां अलग-अलग भागो को अलग करके उन्हें एक में जोड़ना सामान्यतः | ||
सामान्यतः लाभ होता है।}} | |||
प्रोग्रामिंग भाषा की आवश्यकता के रूप में, डेविड ए. श्मिट द्वारा टाइप की गई प्रोग्रामिंग भाषाओं की संरचना (1994) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है:।<ref>David A. Schmidt, ''The structure of typed programming languages'', MIT Press, 1994, {{ISBN|0-262-19349-3}}, p. 32</ref> | प्रोग्रामिंग भाषा की आवश्यकता के रूप में, डेविड ए. श्मिट द्वारा टाइप की गई प्रोग्रामिंग भाषाओं की संरचना (1994) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है:।<ref>David A. Schmidt, ''The structure of typed programming languages'', MIT Press, 1994, {{ISBN|0-262-19349-3}}, p. 32</ref> | ||
{{cquote| | {{cquote|किसी भी अर्थपूर्ण वाक्य-विन्यास वर्ग के वाक्यांशों का नाम दिया जा सकता है।}} | ||
==इतिहास और विविधताएँ== | ==इतिहास और विविधताएँ== | ||
अमूर्तन सिद्धांत का उल्लेख कई पुस्तकों में किया गया है। इनमें से कुछ, सूत्रीकरण के साथ, यदि यह संक्षिप्त है, नीचे सूचीबद्ध हैं। | अमूर्तन सिद्धांत का उल्लेख कई पुस्तकों में किया गया है। इनमें से कुछ, सूत्रीकरण के साथ, यदि यह संक्षिप्त है, नीचे सूचीबद्ध हैं। | ||
* अल्फ्रेड जॉन कोल, रोनाल्ड मॉरिसन (1982) एस-अल्गोल के साथ प्रोग्रामिंग का एक परिचय: [अमूर्त] जब भाषा डिजाइन पर | * अल्फ्रेड जॉन कोल, रोनाल्ड मॉरिसन (1982) एस-अल्गोल के साथ प्रोग्रामिंग का एक परिचय: [अमूर्त] जब भाषा डिजाइन पर प्रयुक्त किया जाता है तो भाषा में सभी अर्थपूर्ण रूप से सार्थक वाक्यविन्यास श्रेणियों को परिभाषित करना और उन पर एक अमूर्तता की अनुमति देना है।<ref>Alfred John Cole, Ronald Morrison, ''An introduction to programming with S-algol'', CUP Archive, 1982, {{ISBN|0-521-25001-3}}, p. 150</ref> | ||
* ब्रूस जे. मैकलेनन (1983) प्रोग्रामिंग भाषाओं के सिद्धांत: डिज़ाइन, मूल्यांकन और कार्यान्वयन: किसी चीज़ को एक से अधिक बार कहने की आवश्यकता से बचें; आवर्ती पैटर्न का कारक | * ब्रूस जे. मैकलेनन (1983) प्रोग्रामिंग भाषाओं के सिद्धांत: डिज़ाइन, मूल्यांकन और कार्यान्वयन: किसी चीज़ को एक से अधिक बार कहने की आवश्यकता से बचें; आवर्ती पैटर्न का कारक निकालते है।<ref>Bruce J. MacLennan, ''Principles of programming languages: design, evaluation, and implementation'', Holt, Rinehart, and Winston, 1983, p. 53</ref> | ||
* जॉन पीयर्स (1998) प्रोग्रामिंग और मेटा-प्रोग्रामिंग इन स्कीम: संरचना और कार्य स्वतंत्र होने चाहिए।<ref>Jon Pearce, ''Programming and meta-programming in scheme'', Birkhäuser, 1998, {{ISBN|0-387-98320-1}}, p. 40</ref> | * जॉन पीयर्स (1998) प्रोग्रामिंग और मेटा-प्रोग्रामिंग इन स्कीम: संरचना और कार्य स्वतंत्र होने चाहिए।<ref>Jon Pearce, ''Programming and meta-programming in scheme'', Birkhäuser, 1998, {{ISBN|0-387-98320-1}}, p. 40</ref> | ||
यह सिद्धांत [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] में [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] में एक केंद्रीय भूमिका निभाता है, | यह सिद्धांत [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] में [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] में एक केंद्रीय भूमिका निभाता है, चूँकि उस विषय पर अधिकांश लेखन सिद्धांत को कोई नाम नहीं देते हैं। गैंग ऑफ फोर द्वारा [[डिज़ाइन पैटर्न (पुस्तक)]]पुस्तक) में कहा गया है: यहां फोकस [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] अवधारणा है जो भिन्न होती है, कई डिजाइन पैटर्न का विषय है। इस कथन को अन्य लेखकों द्वारा इस प्रकार दोहराया गया है कि जो भिन्न है उसे खोजें और उसे संपुटित करें।<ref>Alan Shalloway, James Trott, ''Design patterns explained: a new perspective on object-oriented design'', Addison-Wesley, 2002, {{ISBN|0-201-71594-5}}, p. 115</ref> | ||
इस सदी में, एक बार और केवल एक बार के नारे के तहत [[चरम कार्यक्रम]] में सिद्धांत को फिर से खोजा गया है। इस सिद्धांत की परिभाषा अपनी पहली उपस्थिति में काफी संक्षिप्त थी: कोई डुप्लिकेट कोड | इस सदी में, एक बार और केवल एक बार के नारे के तहत [[चरम कार्यक्रम]] में सिद्धांत को फिर से खोजा गया है। इस सिद्धांत की परिभाषा अपनी पहली उपस्थिति में काफी संक्षिप्त थी: कोई डुप्लिकेट कोड नहीं है।<ref>Kent Beck, ''Extreme programming explained: embrace change'', 2nd edition, Addison-Wesley, 2000, {{ISBN|0-201-61641-6}}, p. 61</ref> इसे बाद में सॉफ़्टवेयर विकास में अन्य उद्देश्य पर प्रयुक्त होने के रूप में विस्तृत किया गया है: स्वचालित करने लायक हर प्रक्रिया को स्वचालित करें। यदि आप स्वयं को कोई कार्य कई बार करते हुए पाते हैं, तो उसे स्क्रिप्ट करते है।<ref>Chromatic, ''Extreme programming pocket guide'', O'Reilly, 2003, {{ISBN|0-596-00485-0}}</ref> | ||
== निहितार्थ == | == निहितार्थ == | ||
अमूर्त सिद्धांत को | अमूर्त सिद्धांत को अधिकांशतः अमूर्तता को सुविधाजनक बनाने के उद्देश्य से कुछ तंत्र के संदर्भ में कहा जाता है। नियंत्रण अमूर्तन का मूल तंत्र एक फ़ंक्शन या [[सबरूटीन]] है। डेटा अमूर्तन में [[बहुरूपता प्रकार]] के विभिन्न रूप सम्मिलित हैं। अधिक विस्तृत तंत्र जो डेटा को संयोजित कर सकते हैं और अमूर्तता को नियंत्रित कर सकते हैं, उनमें सम्मिलित हैं: [[अमूर्त डेटा प्रकार]], जिसमें क्लास (कंप्यूटर विज्ञान), बहुरूपता_(कंप्यूटर_विज्ञान) या बहुरूपता आदि सम्मिलित हैं। जटिल परिदृश्यों में कम दोहराव की अनुमति देने वाले समृद्ध अमूर्तता की तलाश प्रेरक शक्तियों में से एक है। प्रोग्रामिंग भाषा अनुसंधान और डिजाइन। | ||
अनुभवहीन प्रोग्रामर अपने प्रोग्राम में बहुत अधिक अमूर्तता लाने के लिए प्रलोभित हो सकते हैं - अमूर्तता जिसका उपयोग एक से अधिक बार नहीं किया जाएगा। एक पूरक सिद्धांत जो इस | अनुभवहीन प्रोग्रामर अपने प्रोग्राम में बहुत अधिक अमूर्तता लाने के लिए प्रलोभित हो सकते हैं - अमूर्तता जिसका उपयोग एक से अधिक बार नहीं किया जाएगा। एक पूरक सिद्धांत जो इस उद्देश्य पर जोर देता है वह है आपको इसकी आवश्यकता नहीं होगी और, अधिक सामान्यतः किस्स सिद्धांत है। | ||
चूंकि कोड | चूंकि कोड सामान्यतः संशोधन के अधीन होता है, अमूर्त सिद्धांत का पालन करने से कोड को दोबारा बनाने की आवश्यकता हो सकती है। कोड के एक टुकड़े को फिर से लिखने के प्रयास को सामान्यतः एक अमूर्त के अनुमानित भविष्य के लाभों के तुलना परिशोधित करने की आवश्यकता होती है। इसे नियंत्रित करने वाला एक सामान्य नियम [[मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर)]] द्वारा तैयार किया गया था, और तीन के नियम (प्रोग्रामिंग) के रूप में लोकप्रिय हुआ। इसमें कहा गया है कि यदि कोड का एक टुकड़ा दो बार से अधिक कॉपी किया गया है, अर्थात इसकी तीन या अधिक प्रतियां हो जाएंगी तो इसे अलग करना होगा। | ||
== सामान्यीकरण == | == सामान्यीकरण == | ||
डोंट रिपीट योरसेल्फ, या | डोंट रिपीट योरसेल्फ, या ड्राई सिद्धांत, [[बहुस्तरीय वास्तुकला]] के संदर्भ में विकसित एक सामान्यीकरण है, जहां संबंधित कोड को कुछ सीमा तक सभी स्तरों पर, सामान्यतः अलग-अलग भाषाओं में दोहराया जाता है। व्यावहारिक रूप से, यहां पुनरावृत्ति से बचने के लिए [[स्वचालित प्रोग्रामिंग]] और [[डेटा परिवर्तन]] जैसे स्वचालित टूल पर विश्वास करने की पक्षसमर्थन की गई है। | ||
== हार्डवेयर प्रोग्रामिंग इंटरफेस == | == हार्डवेयर प्रोग्रामिंग इंटरफेस == | ||
कोड को अनुकूलित करने के | कोड को अनुकूलित करने के अतिरिक्त, प्रोग्रामिंग में एब्स्ट्रैक्शन स्तर का एक पदानुक्रमित/पुनरावर्ती अर्थ हार्डवेयर संचार परतों के बीच इंटरफेस को भी संदर्भित करता है, जिसे एब्स्ट्रैक्शन स्तर और एब्स्ट्रैक्शन परतें भी कहा जाता है। इस स्थिति में, अमूर्तता का स्तर अधिकांशतः इंटरफ़ेस का पर्याय होता है। उदाहरण के लिए, शेलकोड और उच्च और निम्न स्तर की भाषाओं के बीच इंटरफेस की जांच में, अमूर्तता का स्तर ऑपरेटिंग सिस्टम कमांड (उदाहरण के लिए, सी में) से रजिस्टर और परिपथ स्तर कॉल और कमांड (उदाहरण के लिए, असेंबली और बाइनरी में) में बदल जाता है। उस उदाहरण के स्थिति में, अमूर्त स्तरों के बीच की सीमा या इंटरफ़ेस स्टैक है।<ref>Koziol, ''The Shellcoders Handbook"'', Wiley, 2004, p. 10, {{ISBN|0-7645-4468-3}}</ref> | ||
==संदर्भ == | |||
==संदर्भ== | |||
{{reflist}} | {{reflist}} | ||
[[Category:Created On 26/06/2023]] | [[Category:Created On 26/06/2023]] | ||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with script errors]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:प्रोग्रामिंग भाषा विषय]] | |||
[[Category:प्रोग्रामिंग सिद्धांत]] |
Latest revision as of 16:23, 8 July 2023
सॉफ्टवेयर इंजीनियरिंग और प्रोग्रामिंग भाषा सिद्धांत में, अमूर्त सिद्धांत (या अमूर्त का सिद्धांत) एक मूलभूत सिद्धांत है जिसका उद्देश्य अमूर्त (कंप्यूटर विज्ञान) का उपयोग करके किसी प्रोग्राम में जानकारी के दोहराव को कम करना है (सामान्यतः कोड दोहराव पर जोर देने के साथ) )एस प्रोग्रामिंग भाषा या सॉफ़्टवेयर लाइब्रेरी द्वारा प्रदान किया जाता है सिद्धांत को कभी-कभी प्रोग्रामर के लिए एक अनुशंसा के रूप में कहा जाता है, किंतु कभी-कभी इसे प्रोग्रामिंग भाषा की आवश्यकता के रूप में भी कहा जाता है, यह मानते हुए कि यह स्व-समझ में आता है कि क्यों अमूर्त का उपयोग करना वांछनीय है। सिद्धांत की उत्पत्ति अनिश्चित है;इसे कई बार कभी-कभी थोड़े बदलावों के साथ एक अलग नाम के तहत पुनर्निर्मित किया गया है।
जब प्रोग्रामर की पक्षसमर्थन के रूप में पढ़ा जाता है, तो अमूर्त सिद्धांत को स्वयं को न दोहराने (ड्राई ) सिद्धांत के रूप में सामान्यीकृत किया जा सकता है, जो सामान्य रूप से जानकारी के दोहराव से बचने की पक्षसमर्थन करता है, और सॉफ्टवेयर विकास प्रक्रिया में सम्मिलित मानव प्रयास के दोहराव से भी बचाता है। .
सिद्धांत
प्रोग्रामर को एक अनुशंसा के रूप में, बेंजामिन सी पियर्स द्वारा प्रकार और प्रोग्रामिंग भाषाएँ (2002) में इसके निर्माण में, अमूर्त सिद्धांत (मूल में जोर) पढ़ता है:[1]
किसी प्रोग्राम में प्रत्येक महत्वपूर्ण कार्यक्षमता को स्रोत कोड में केवल एक ही स्थान पर प्रयुक्त किया जाना चाहिए। जहां समान कार्य कोड के अलग-अलग टुकड़ों द्वारा किए जाते हैं, वहां अलग-अलग भागो को अलग करके उन्हें एक में जोड़ना सामान्यतः सामान्यतः लाभ होता है।
प्रोग्रामिंग भाषा की आवश्यकता के रूप में, डेविड ए. श्मिट द्वारा टाइप की गई प्रोग्रामिंग भाषाओं की संरचना (1994) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है:।[2]
किसी भी अर्थपूर्ण वाक्य-विन्यास वर्ग के वाक्यांशों का नाम दिया जा सकता है।
इतिहास और विविधताएँ
अमूर्तन सिद्धांत का उल्लेख कई पुस्तकों में किया गया है। इनमें से कुछ, सूत्रीकरण के साथ, यदि यह संक्षिप्त है, नीचे सूचीबद्ध हैं।
- अल्फ्रेड जॉन कोल, रोनाल्ड मॉरिसन (1982) एस-अल्गोल के साथ प्रोग्रामिंग का एक परिचय: [अमूर्त] जब भाषा डिजाइन पर प्रयुक्त किया जाता है तो भाषा में सभी अर्थपूर्ण रूप से सार्थक वाक्यविन्यास श्रेणियों को परिभाषित करना और उन पर एक अमूर्तता की अनुमति देना है।[3]
- ब्रूस जे. मैकलेनन (1983) प्रोग्रामिंग भाषाओं के सिद्धांत: डिज़ाइन, मूल्यांकन और कार्यान्वयन: किसी चीज़ को एक से अधिक बार कहने की आवश्यकता से बचें; आवर्ती पैटर्न का कारक निकालते है।[4]
- जॉन पीयर्स (1998) प्रोग्रामिंग और मेटा-प्रोग्रामिंग इन स्कीम: संरचना और कार्य स्वतंत्र होने चाहिए।[5]
यह सिद्धांत ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में डिज़ाइन पैटर्न (कंप्यूटर विज्ञान) में एक केंद्रीय भूमिका निभाता है, चूँकि उस विषय पर अधिकांश लेखन सिद्धांत को कोई नाम नहीं देते हैं। गैंग ऑफ फोर द्वारा डिज़ाइन पैटर्न (पुस्तक)पुस्तक) में कहा गया है: यहां फोकस एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) अवधारणा है जो भिन्न होती है, कई डिजाइन पैटर्न का विषय है। इस कथन को अन्य लेखकों द्वारा इस प्रकार दोहराया गया है कि जो भिन्न है उसे खोजें और उसे संपुटित करें।[6]
इस सदी में, एक बार और केवल एक बार के नारे के तहत चरम कार्यक्रम में सिद्धांत को फिर से खोजा गया है। इस सिद्धांत की परिभाषा अपनी पहली उपस्थिति में काफी संक्षिप्त थी: कोई डुप्लिकेट कोड नहीं है।[7] इसे बाद में सॉफ़्टवेयर विकास में अन्य उद्देश्य पर प्रयुक्त होने के रूप में विस्तृत किया गया है: स्वचालित करने लायक हर प्रक्रिया को स्वचालित करें। यदि आप स्वयं को कोई कार्य कई बार करते हुए पाते हैं, तो उसे स्क्रिप्ट करते है।[8]
निहितार्थ
अमूर्त सिद्धांत को अधिकांशतः अमूर्तता को सुविधाजनक बनाने के उद्देश्य से कुछ तंत्र के संदर्भ में कहा जाता है। नियंत्रण अमूर्तन का मूल तंत्र एक फ़ंक्शन या सबरूटीन है। डेटा अमूर्तन में बहुरूपता प्रकार के विभिन्न रूप सम्मिलित हैं। अधिक विस्तृत तंत्र जो डेटा को संयोजित कर सकते हैं और अमूर्तता को नियंत्रित कर सकते हैं, उनमें सम्मिलित हैं: अमूर्त डेटा प्रकार, जिसमें क्लास (कंप्यूटर विज्ञान), बहुरूपता_(कंप्यूटर_विज्ञान) या बहुरूपता आदि सम्मिलित हैं। जटिल परिदृश्यों में कम दोहराव की अनुमति देने वाले समृद्ध अमूर्तता की तलाश प्रेरक शक्तियों में से एक है। प्रोग्रामिंग भाषा अनुसंधान और डिजाइन।
अनुभवहीन प्रोग्रामर अपने प्रोग्राम में बहुत अधिक अमूर्तता लाने के लिए प्रलोभित हो सकते हैं - अमूर्तता जिसका उपयोग एक से अधिक बार नहीं किया जाएगा। एक पूरक सिद्धांत जो इस उद्देश्य पर जोर देता है वह है आपको इसकी आवश्यकता नहीं होगी और, अधिक सामान्यतः किस्स सिद्धांत है।
चूंकि कोड सामान्यतः संशोधन के अधीन होता है, अमूर्त सिद्धांत का पालन करने से कोड को दोबारा बनाने की आवश्यकता हो सकती है। कोड के एक टुकड़े को फिर से लिखने के प्रयास को सामान्यतः एक अमूर्त के अनुमानित भविष्य के लाभों के तुलना परिशोधित करने की आवश्यकता होती है। इसे नियंत्रित करने वाला एक सामान्य नियम मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) द्वारा तैयार किया गया था, और तीन के नियम (प्रोग्रामिंग) के रूप में लोकप्रिय हुआ। इसमें कहा गया है कि यदि कोड का एक टुकड़ा दो बार से अधिक कॉपी किया गया है, अर्थात इसकी तीन या अधिक प्रतियां हो जाएंगी तो इसे अलग करना होगा।
सामान्यीकरण
डोंट रिपीट योरसेल्फ, या ड्राई सिद्धांत, बहुस्तरीय वास्तुकला के संदर्भ में विकसित एक सामान्यीकरण है, जहां संबंधित कोड को कुछ सीमा तक सभी स्तरों पर, सामान्यतः अलग-अलग भाषाओं में दोहराया जाता है। व्यावहारिक रूप से, यहां पुनरावृत्ति से बचने के लिए स्वचालित प्रोग्रामिंग और डेटा परिवर्तन जैसे स्वचालित टूल पर विश्वास करने की पक्षसमर्थन की गई है।
हार्डवेयर प्रोग्रामिंग इंटरफेस
कोड को अनुकूलित करने के अतिरिक्त, प्रोग्रामिंग में एब्स्ट्रैक्शन स्तर का एक पदानुक्रमित/पुनरावर्ती अर्थ हार्डवेयर संचार परतों के बीच इंटरफेस को भी संदर्भित करता है, जिसे एब्स्ट्रैक्शन स्तर और एब्स्ट्रैक्शन परतें भी कहा जाता है। इस स्थिति में, अमूर्तता का स्तर अधिकांशतः इंटरफ़ेस का पर्याय होता है। उदाहरण के लिए, शेलकोड और उच्च और निम्न स्तर की भाषाओं के बीच इंटरफेस की जांच में, अमूर्तता का स्तर ऑपरेटिंग सिस्टम कमांड (उदाहरण के लिए, सी में) से रजिस्टर और परिपथ स्तर कॉल और कमांड (उदाहरण के लिए, असेंबली और बाइनरी में) में बदल जाता है। उस उदाहरण के स्थिति में, अमूर्त स्तरों के बीच की सीमा या इंटरफ़ेस स्टैक है।[9]
संदर्भ
- ↑ Pierce, Benjamin (2002). प्रकार और प्रोग्रामिंग भाषाएँ. MIT Press. p. 339. ISBN 0-262-16209-1.
- ↑ David A. Schmidt, The structure of typed programming languages, MIT Press, 1994, ISBN 0-262-19349-3, p. 32
- ↑ Alfred John Cole, Ronald Morrison, An introduction to programming with S-algol, CUP Archive, 1982, ISBN 0-521-25001-3, p. 150
- ↑ Bruce J. MacLennan, Principles of programming languages: design, evaluation, and implementation, Holt, Rinehart, and Winston, 1983, p. 53
- ↑ Jon Pearce, Programming and meta-programming in scheme, Birkhäuser, 1998, ISBN 0-387-98320-1, p. 40
- ↑ Alan Shalloway, James Trott, Design patterns explained: a new perspective on object-oriented design, Addison-Wesley, 2002, ISBN 0-201-71594-5, p. 115
- ↑ Kent Beck, Extreme programming explained: embrace change, 2nd edition, Addison-Wesley, 2000, ISBN 0-201-61641-6, p. 61
- ↑ Chromatic, Extreme programming pocket guide, O'Reilly, 2003, ISBN 0-596-00485-0
- ↑ Koziol, The Shellcoders Handbook", Wiley, 2004, p. 10, ISBN 0-7645-4468-3