मतिहीनता (कंप्यूटर विज्ञान)

The essence of abstraction is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context.

– John V. Guttag^[1]

सॉफ्टवेयर इंजीनियरिंग और कंप्यूटर विज्ञान में, अमूर्तता है:

भौतिक, स्थानिक, या लौकिक विवरणों को हटाने या सामान्य बनाने की प्रक्रिया^[2] या अधिक महत्व के विवरण पर ध्यान केंद्रित करने के लिए वस्तुओं या प्रणालियों के अध्ययन में गुण (कंप्यूटिंग);^[3] यह प्रकृति में सामान्यीकरण की प्रक्रिया के समान है;
विभिन्न गैर-अमूर्त वस्तुओं या अध्ययन की प्रणालियों की सामान्य विशेषताओं या विशेषताओं को प्रतिबिंबित करके सार और ठोस अवधारणा-वस्तु (दर्शन) का निर्माण^[3]- अमूर्तन की प्रक्रिया का परिणाम।

एब्स्ट्रेक्शन | एब्सट्रैक्शन, सामान्य रूप से, कंप्यूटर विज्ञान और सॉफ्टवेयर विकास में एक मौलिक अवधारणा है।^[4] अमूर्तन की प्रक्रिया को मॉडलिंग के रूप में भी संदर्भित किया जा सकता है और यह सिद्धांत और डिज़ाइन की अवधारणाओं से निकटता से संबंधित है।^[5] अवधारणात्मक मॉडल को वास्तविकता के पहलुओं के सामान्यीकरण के अनुसार सार के प्रकार भी माना जा सकता है।

कंप्यूटर विज्ञान में अमूर्तता अमूर्तता (गणित) से निकटता से संबंधित है, क्योंकि वस्तुओं के रूप में अमूर्तता के निर्माण पर उनका सामान्य ध्यान है,^[2]लेकिन अन्य क्षेत्रों में अमूर्तता (कला) में प्रयुक्त अमूर्तता की अन्य धारणाओं से भी संबंधित है।^[3]

अमूर्त वास्तविक दुनिया की वस्तुओं और प्रणालियों, संगणना के नियमों या प्रोग्रामिंग भाषाओं के नियमों का भी उल्लेख कर सकते हैं जो अमूर्तता की विशेषताओं को ले जाते हैं या उनका उपयोग करते हैं, जैसे:

कंप्यूटर प्रोग्राम के भीतर डेटा संरचनाओं के कार्य प्रतिनिधित्व से उपयोग को अलग करने के लिए डेटा अमूर्त करने के लिए डेटा प्रकारों का उपयोग;^[6]
प्रक्रिया (कंप्यूटर विज्ञान) की अवधारणा | प्रक्रियाएं, कार्य, या सबरूटीन्स जो कार्यक्रमों में नियंत्रण प्रवाह को लागू करने का एक विशिष्ट प्रतिनिधित्व करते हैं;
लैम्ब्डा कैलकुलस के विभिन्न संस्करणों में मुक्त चर और बाध्य चर का उपयोग करके एक्सप्रेशन (गणित) को सामान्यीकृत करने वाले सामान्य नाम के नियम;^[7]^[8]
लिस्प (प्रोग्रामिंग भाषा) में डेटा संरचनाओं और कार्यक्रमों के अमूर्त के रूप में एस-अभिव्यक्ति का उपयोग;^[9]
गैर-अमूर्त वर्ग (कंप्यूटर प्रोग्रामिंग) से सामान्य व्यवहार को पुनर्गठित करने की प्रक्रिया वंशानुक्रम (ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग) का उपयोग करके सार वर्गों में विरासत (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) पर अमूर्त करने के लिए # उप-वर्ग और सुपरक्लास | उप-वर्ग जैसा कि ऑब्जेक्ट में देखा गया है -ओरिएंटेड प्रोग्रामिंग|ऑब्जेक्ट-ओरिएंटेड सी ++ और जावा (प्रोग्रामिंग भाषा) प्रोग्रामिंग लैंग्वेज।

तर्क

कंप्यूटिंग ज्यादातर ठोस दुनिया से स्वतंत्र रूप से संचालित होती है। हार्डवेयर संगणना के एक मॉडल को लागू करता है जो दूसरों के साथ विनिमेय है।^[10] सॉफ़्टवेयर को सॉफ़्टवेयर आर्किटेक्चर में संरचित किया गया है ताकि मनुष्य एक समय में कुछ मुद्दों पर ध्यान केंद्रित करके विशाल सिस्टम बना सकें। ये आर्किटेक्चर अमूर्त के विशिष्ट विकल्पों से बने हैं। ग्रीनस्पन का दसवां नियम इस बात पर आधारित है कि इस तरह की वास्तुकला अपरिहार्य और जटिल दोनों है।

कंप्यूटिंग में अमूर्तता का एक केंद्रीय रूप भाषा अमूर्तता है: सिस्टम के विशिष्ट पहलुओं को व्यक्त करने के लिए नई कृत्रिम भाषाएं विकसित की जाती हैं। मॉडलिंग भाषाएँ योजना बनाने में मदद करती हैं। कंप्यूटर भाषाओं को कंप्यूटर से संसाधित किया जा सकता है। इस अमूर्त प्रक्रिया का एक उदाहरण पहली पीढ़ी की प्रोग्रामिंग भाषा से दूसरी पीढ़ी की प्रोग्रामिंग भाषा और तीसरी पीढ़ी की प्रोग्रामिंग भाषा | उच्च-स्तरीय भाषा में प्रोग्रामिंग भाषाओं का पीढ़ीगत विकास है। प्रत्येक चरण को अगले चरण के लिए एक सोपान के रूप में उपयोग किया जा सकता है। उदाहरण के लिए स्क्रिप्टिंग भाषाओं और डोमेन-विशिष्ट प्रोग्रामिंग भाषाओं में भाषा अमूर्तता जारी है।

एक प्रोग्रामिंग भाषा के भीतर, कुछ विशेषताएं प्रोग्रामर को नए सार बनाने देती हैं। इनमें सबरूटीन्स, मॉड्यूल (प्रोग्रामिंग), बहुरूपता (कंप्यूटर विज्ञान), और सॉफ्टवेयर घटक शामिल हैं। कुछ अन्य सार जैसे सॉफ्टवेयर डिजाइन पैटर्न और सॉफ़्टवेयर वास्तुशिल्प #आर्किटेक्चर उदाहरण एक अनुवादक (कंप्यूटिंग) के लिए अदृश्य रहते हैं और केवल एक सिस्टम के डिजाइन में काम करते हैं।

कुछ सार उन अवधारणाओं की सीमा को सीमित करने का प्रयास करते हैं जिनके बारे में एक प्रोग्रामर को जागरूक होने की आवश्यकता होती है, उन अमूर्तताओं को पूरी तरह छुपाकर जिन्हें वे बदले में बनाए जाते हैं। सॉफ्टवेयर इंजीनियर और लेखक जोएल स्पोल्स्की ने इन प्रयासों की यह दावा करते हुए आलोचना की है कि सभी सार लीकी अमूर्त हैं - कि वे नीचे दिए गए विवरणों को पूरी तरह से कभी नहीं छिपा सकते हैं;^[11] हालाँकि, यह अमूर्तता की उपयोगिता को नकारता नहीं है।

कुछ सार को अन्य सार के साथ इंटर-ऑपरेट करने के लिए डिज़ाइन किया गया है - उदाहरण के लिए, एक प्रोग्रामिंग भाषा में निचले स्तर की भाषा में कॉल करने के लिए एक विदेशी फ़ंक्शन इंटरफ़ेस हो सकता है।

अमूर्त विशेषताएं

प्रोग्रामिंग लैंग्वेज

विभिन्न प्रोग्रामिंग लैंग्वेज भाषा के लिए इच्छित अनुप्रयोगों के आधार पर विभिन्न प्रकार के अमूर्तता प्रदान करती हैं। उदाहरण के लिए:

वस्तु-उन्मुख प्रोग्रामिंग भाषा जैसे C++, वस्तु पास्कल, या जावा (प्रोग्रामिंग लैंग्वेज) में, अमूर्तता की अवधारणा स्वयं एक घोषणात्मक कथन बन गई है - सिंटेक्स (प्रोग्रामिंग लैंग्वेज) का उपयोग करके function(parameters) = 0; (C++ में) या कीवर्ड (कंप्यूटर प्रोग्रामिंग)।abstract^[12] औरinterface^[13] (जावा में (प्रोग्रामिंग भाषा))। इस तरह की घोषणा के बाद, यह प्रोग्रामर की जिम्मेदारी है कि वह घोषणा के ऑब्जेक्ट (कंप्यूटर साइंस) को इंस्टैंट करने के लिए एक क्लास (कंप्यूटर साइंस) को लागू करे।
कार्यात्मक प्रोग्रामिंग भाषाएं आमतौर पर कार्यों से संबंधित अमूर्तताएं प्रदर्शित करती हैं, जैसे कि लैम्ब्डा अमूर्त (कुछ चर के कार्य में एक शब्द बनाना) और उच्च-क्रम के कार्य (पैरामीटर कार्य हैं)।
लिस्प प्रोग्रामिंग लैंग्वेज परिवार के आधुनिक सदस्य जैसे क्लोजर, स्कीम (प्रोग्रामिंग लैंग्वेज) और सामान्य लिस्प मैक्रो (कंप्यूटर साइंस) # सिंटैक्टिक मैक्रोज़ को सिंटैक्टिक एब्स्ट्रैक्शन की अनुमति देते हैं। अन्य प्रोग्रामिंग भाषाओं जैसे स्काला (प्रोग्रामिंग भाषा) में भी मैक्रोज़ या बहुत समान मेटाप्रोग्रामिंग सुविधाएँ हैं (उदाहरण के लिए, हास्केल (प्रोग्रामिंग भाषा) में टेम्पलेट हास्केल है, और OCaml में मेटाओकैमल है)। ये एक प्रोग्रामर को बॉयलरप्लेट कोड को खत्म करने, थकाऊ फ़ंक्शन कॉल अनुक्रमों को दूर करने, नए नियंत्रण प्रवाह को लागू करने और डोमेन-विशिष्ट भाषा को लागू करने की अनुमति दे सकते हैं। डोमेन विशिष्ट भाषाएँ (डीएसएल), जो डोमेन-विशिष्ट अवधारणाओं को संक्षिप्त और सुरुचिपूर्ण तरीके से व्यक्त करने की अनुमति देती हैं। . इन सभी का, जब सही तरीके से उपयोग किया जाता है, तो इच्छित उद्देश्य को और अधिक स्पष्ट करके प्रोग्रामर की दक्षता और कोड की स्पष्टता दोनों में सुधार होता है। वाक्यात्मक अमूर्तता का एक परिणाम यह भी है कि किसी भी लिस्प बोली और वास्तव में लगभग किसी भी प्रोग्रामिंग भाषा को, सिद्धांत रूप में, किसी भी आधुनिक लिस्प में काफी कम (लेकिन अभी भी ज्यादातर मामलों में गैर-तुच्छ) प्रयास के साथ लागू किया जा सकता है जब अधिक पारंपरिक प्रोग्रामिंग भाषाओं की तुलना में जैसे कि पायथन (प्रोग्रामिंग भाषा), सी (प्रोग्रामिंग भाषा) या जावा (प्रोग्रामिंग भाषा)।

विशिष्टता के तरीके

विश्लेषकों ने सॉफ्टवेयर सिस्टम को औपचारिक रूप से निर्दिष्ट करने के लिए विभिन्न तरीके विकसित किए हैं। कुछ ज्ञात विधियों में शामिल हैं:

सार-मॉडल आधारित पद्धति (वीडीएम, जेड);
बीजगणितीय तकनीकें (लार्च, क्लियर, ओबीजे, एक्ट वन, सीएएसएल);
प्रक्रिया-आधारित तकनीकें (LOTOS, SDL, Estelle);
ट्रेस-आधारित तकनीकें (विशेष, टैम);
ज्ञान आधारित तकनीकें (परिष्कृत, सार)।

विशिष्टता भाषाएं

विशिष्टता भाषाएं आम तौर पर एक या दूसरे प्रकार के सार पर भरोसा करती हैं, क्योंकि विशिष्टताओं को आमतौर पर एक परियोजना में पहले परिभाषित किया जाता है, (और अधिक सार स्तर पर) एक अंतिम कार्यान्वयन से। एकीकृत मॉडलिंग भाषा स्पेसिफिकेशंस लैंग्वेज, उदाहरण के लिए, अमूर्त वर्गों की परिभाषा की अनुमति देती है, जो एक जलप्रपात परियोजना में, परियोजना के आर्किटेक्चर और विनिर्देशन चरण के दौरान अमूर्त रहते हैं।

अमूर्त नियंत्रण

प्रोग्रामिंग भाषाएं उनके उपयोग के मुख्य उद्देश्यों में से एक के रूप में नियंत्रण अमूर्तता प्रदान करती हैं। कंप्यूटर मशीनें बहुत निम्न स्तर पर संचालन को समझती हैं जैसे कुछ बिट्स को मेमोरी के एक स्थान से दूसरे स्थान पर ले जाना और बिट्स के दो अनुक्रमों का योग बनाना। प्रोग्रामिंग लैंग्वेज इसे उच्च स्तर पर करने की अनुमति देती हैं। उदाहरण के लिए, पास्कल (प्रोग्रामिंग भाषा) जैसी शैली में लिखे गए इस कथन पर विचार करें:

a := (1 + 2) * 5

एक मानव के लिए, यह एक काफी सरल और स्पष्ट गणना लगती है (एक और दो तीन होते हैं, पांच का गुणा पंद्रह होता है)। हालांकि, इस मूल्यांकन को करने के लिए आवश्यक निम्न-स्तरीय कदम, और मान 15 लौटाते हैं, और फिर उस मान को वेरिएबल a पर असाइन करते हैं, वास्तव में काफी सूक्ष्म और जटिल हैं। मूल्यों को बाइनरी प्रतिनिधित्व में परिवर्तित करने की आवश्यकता होती है (अक्सर एक से अधिक जटिल कार्य जो किसी को लगता है) और विधानसभा निर्देशों में विघटित गणना (संकलक या दुभाषिया द्वारा) (फिर से, जो प्रोग्रामर के लिए बहुत कम सहज हैं: संचालन जैसे कि एक बायनरी रजिस्टर को बायीं ओर स्थानांतरित करना, या एक रजिस्टर की सामग्री के बायनरी पूरक को दूसरे में जोड़ना, बस यह नहीं है कि मनुष्य जोड़ या गुणन के सार अंकगणितीय संचालन के बारे में कैसे सोचते हैं)। अंत में, a लेबल वाले चर को 15 का परिणामी मान निर्दिष्ट करना, ताकि बाद में a का उपयोग किया जा सके, चर के लेबल को देखने के अतिरिक्त 'पीछे-पीछे' चरण शामिल हैं और भौतिक या आभासी स्मृति में परिणामी स्थान, भंडारण उस मेमोरी लोकेशन आदि के लिए 15 का बाइनरी प्रतिनिधित्व।

नियंत्रण अमूर्तता के बिना, एक प्रोग्रामर को हर बार सभी रजिस्टर/बाइनरी-स्तर के चरणों को निर्दिष्ट करने की आवश्यकता होगी, जब वे बस कुछ संख्याओं को जोड़ना या गुणा करना चाहते थे और परिणाम को एक चर के रूप में निर्दिष्ट करना चाहते थे। प्रयास के ऐसे दोहराव के दो गंभीर नकारात्मक परिणाम होते हैं:

यह प्रोग्रामर को हर बार एक समान ऑपरेशन की आवश्यकता होने पर काफी सामान्य कार्यों को लगातार दोहराने के लिए मजबूर करता है
यह प्रोग्रामर को विशेष हार्डवेयर और निर्देश सेट के लिए प्रोग्राम करने के लिए बाध्य करता है

संरचित प्रोग्रामिंग

संरचित प्रोग्रामिंग में जटिल प्रोग्राम कार्यों को स्पष्ट प्रवाह-नियंत्रण और घटकों के बीच इंटरफेस के साथ छोटे टुकड़ों में विभाजित करना शामिल है, जिससे साइड-इफेक्ट्स की जटिलता क्षमता में कमी आती है।

एक साधारण कार्यक्रम में, यह सुनिश्चित करने का लक्ष्य हो सकता है कि लूप में एकल या स्पष्ट निकास बिंदु हों और (जहां संभव हो) कार्यों और प्रक्रियाओं से एकल निकास बिंदु हों।

एक बड़ी प्रणाली में, इसमें जटिल कार्यों को कई अलग-अलग मॉड्यूल में तोड़ना शामिल हो सकता है। एक प्रणाली पर विचार करें जो जहाजों और किनारे के कार्यालयों में पेरोल संभालती है:

सबसे ऊपर के स्तर में विशिष्ट अंत-उपयोगकर्ता संचालन का एक मेनू हो सकता है।
इसके भीतर कर्मचारियों या प्रिंटिंग चेक पर हस्ताक्षर करने और बंद करने जैसे कार्यों के लिए स्टैंडअलोन निष्पादन योग्य या पुस्तकालय हो सकते हैं।
उन प्रत्येक स्टैंडअलोन घटकों के भीतर कई अलग-अलग स्रोत फ़ाइलें हो सकती हैं, जिनमें से प्रत्येक में समस्या के एक हिस्से को संभालने के लिए प्रोग्राम कोड होता है, जिसमें प्रोग्राम के अन्य भागों के लिए केवल चयनित इंटरफेस उपलब्ध होते हैं। एक साइन ऑन प्रोग्राम में प्रत्येक डेटा एंट्री स्क्रीन और डेटाबेस इंटरफ़ेस के लिए स्रोत फ़ाइलें हो सकती हैं (जो स्वयं एक स्टैंडअलोन थर्ड पार्टी लाइब्रेरी या लाइब्रेरी रूटीन का स्टैटिकली लिंक्ड सेट हो सकता है)।
या तो डेटाबेस या पेरोल एप्लिकेशन को भी जहाज और किनारे के बीच डेटा के आदान-प्रदान की प्रक्रिया शुरू करनी होती है, और उस डेटा ट्रांसफर कार्य में अक्सर कई अन्य घटक होते हैं।

ये परतें एक घटक के कार्यान्वयन विवरण और इसके मिश्रित आंतरिक तरीकों को दूसरों से अलग करने का प्रभाव उत्पन्न करती हैं। वस्तु-उन्मुख प्रोग्रामिंग इस अवधारणा को गले लगाती है और विस्तारित करती है।

डेटा अमूर्तता

डेटा अमूर्त डेटा प्रकार के अमूर्त गुणों और इसके कार्यान्वयन के ठोस विवरण के बीच स्पष्ट अलगाव को लागू करता है। सार गुण वे हैं जो क्लाइंट कोड को दिखाई देते हैं जो डेटा प्रकार का उपयोग करता है - डेटा प्रकार के लिए इंटरफ़ेस - जबकि ठोस कार्यान्वयन पूरी तरह से निजी रखा जाता है, और वास्तव में बदल सकता है, उदाहरण के लिए समय के साथ दक्षता में सुधार शामिल करने के लिए। विचार यह है कि इस तरह के परिवर्तनों का क्लाइंट कोड पर कोई प्रभाव नहीं पड़ता है, क्योंकि वे अमूर्त व्यवहार में कोई अंतर नहीं रखते हैं।

उदाहरण के लिए, लुकअप टेबल नामक एक अमूर्त डेटा प्रकार को परिभाषित किया जा सकता है जो विशिष्ट रूप से कुंजियों को मूल्यों के साथ जोड़ता है, और जिसमें मूल्यों को उनकी संबंधित कुंजियों को निर्दिष्ट करके पुनर्प्राप्त किया जा सकता है। ऐसी लुकअप तालिका को विभिन्न तरीकों से लागू किया जा सकता है: एक हैश तालिका के रूप में, एक बाइनरी सर्च ट्री, या यहां तक कि (कुंजी: मान) जोड़े की एक साधारण रैखिक सूची (कंप्यूटिंग)। जहाँ तक क्लाइंट कोड का संबंध है, प्रकार के सार गुण प्रत्येक मामले में समान हैं।

बेशक, यह सब पहली बार में ही इंटरफ़ेस के विवरण प्राप्त करने पर निर्भर करता है, क्योंकि किसी भी बदलाव का क्लाइंट कोड पर बड़ा प्रभाव पड़ सकता है। इसे देखने के एक तरीके के रूप में: इंटरफ़ेस डेटा प्रकार और क्लाइंट कोड के बीच सहमत व्यवहार पर एक अनुबंध बनाता है; अनुबंध में कुछ भी नहीं बताया गया है, बिना सूचना के परिवर्तन के अधीन है।

मैनुअल डेटा अमूर्त

जबकि अधिकांश डेटा अमूर्त कंप्यूटर विज्ञान और स्वचालन के माध्यम से होता है, ऐसे समय होते हैं जब यह प्रक्रिया मैन्युअल रूप से और प्रोग्रामिंग हस्तक्षेप के बिना की जाती है। एक तरह से इसे समझा जा सकता है साहित्य की एक व्यवस्थित समीक्षा करने की प्रक्रिया के भीतर डेटा सार के माध्यम से। इस पद्धति में, मेटा-विश्लेषण करते समय डेटा को एक या कई सारकों द्वारा अमूर्त किया जाता है, जिसमें दोहरी डेटा अमूर्तता के माध्यम से त्रुटियों को कम किया जाता है, जिसके बाद स्वतंत्र जांच होती है, जिसे अधिनिर्णय के रूप में जाना जाता है।^[14]

== ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग == में अमूर्तता

वस्तु-उन्मुख प्रोग्रामिंग सिद्धांत में, अमूर्तता में उन वस्तुओं को परिभाषित करने की सुविधा शामिल होती है जो अमूर्त अभिनेताओं का प्रतिनिधित्व करती हैं जो कार्य कर सकते हैं, रिपोर्ट कर सकते हैं और अपनी स्थिति बदल सकते हैं, और सिस्टम में अन्य वस्तुओं के साथ संवाद कर सकते हैं। एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) शब्द राज्य (कंप्यूटर विज्ञान) के विवरण को छिपाने के लिए संदर्भित करता है, लेकिन डेटा के साथ सबसे दृढ़ता से 'व्यवहार' को जोड़ने के लिए पहले की प्रोग्रामिंग भाषाओं से 'डेटा प्रकार' की अवधारणा का विस्तार करता है, और जिस तरह से विभिन्न डेटा प्रकार परस्पर क्रिया करते हैं, उसका मानकीकरण अमूर्तता की शुरुआत है। जब अमूर्त परिभाषित कार्यों में आगे बढ़ता है, तो विभिन्न प्रकार की वस्तुओं को प्रतिस्थापित करने में सक्षम बनाता है, इसे बहुरूपता (कंप्यूटर विज्ञान) कहा जाता है। जब यह विपरीत दिशा में आगे बढ़ता है, प्रकारों या वर्गों के अंदर, संबंधों के एक जटिल सेट को सरल बनाने के लिए उन्हें संरचित करना, इसे प्रत्यायोजन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) या वंशानुक्रम (कंप्यूटर विज्ञान) कहा जाता है।

विभिन्न वस्तु-उन्मुख प्रोग्रामिंग भाषाएं अमूर्तता के लिए समान सुविधाएं प्रदान करती हैं, सभी वस्तु-उन्मुख प्रोग्रामिंग में बहुरूपता (कंप्यूटर विज्ञान) की एक सामान्य रणनीति का समर्थन करने के लिए, जिसमें समान या समान भूमिका में दूसरे के लिए वस्तु-उन्मुख प्रोग्रामिंग में विन्यास प्रकार का प्रतिस्थापन शामिल है। . यद्यपि आम तौर पर समर्थित नहीं है, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग या छवि या पैकेज में एक कॉन्फ़िगरेशन संकलन-समय, लिंक समय या लोड होने का समय पर बाध्यकारी इनमें से कई नामों को पूर्व निर्धारित कर सकता है। यह रन टाइम (प्रोग्राम जीवनचक्र चरण) | रन-टाइम पर बदलने के लिए केवल न्यूनतम नाम बंधन छोड़ देगा।

कॉमन लिस्प ऑब्जेक्ट सिस्टम या स्वयं (प्रोग्रामिंग भाषा), उदाहरण के लिए, क्लास-इंस्टेंस डिस्टिंक्शन की कम सुविधा प्रतिनिधिमंडल (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) में बहुरूपता के लिए डेलिगेशन का अधिक उपयोग। लिस्प प्रोग्रामिंग भाषा से साझा कार्यात्मक विरासत के साथ बेहतर फिट होने के लिए व्यक्तिगत वस्तुओं और कार्यों को अधिक लचीले ढंग से अमूर्त किया जाता है।

C++ एक और चरम का उदाहरण देता है: यह सामान्य प्रोग्रामिंग और विधि अधिभार और संकलन समय पर अन्य स्टैटिक बाइंडिंग पर बहुत अधिक निर्भर करता है, जिसके बदले में कुछ लचीलेपन की समस्या होती है।

हालांकि ये उदाहरण एक ही सार को प्राप्त करने के लिए वैकल्पिक रणनीतियों की पेशकश करते हैं, लेकिन वे मूल रूप से कोड में अमूर्त संज्ञाओं का समर्थन करने की आवश्यकता को नहीं बदलते हैं - सभी प्रोग्रामिंग कार्यों के रूप में अमूर्त क्रियाओं की क्षमता, डेटा संरचनाओं के रूप में संज्ञाएं, और या तो प्रक्रियाओं के रूप में निर्भर करती हैं।

उदाहरण के लिए एक नमूना जावा (प्रोग्रामिंग लैंग्वेज) के टुकड़े पर विचार करें, जो कुछ सामान्य खेत जानवरों को उनकी भूख और भोजन के सरल पहलुओं के मॉडल के लिए उपयुक्त अमूर्तता के स्तर पर प्रस्तुत करता है। यह एक परिभाषित करता है Animal वर्ग जानवर की स्थिति और उसके कार्यों दोनों का प्रतिनिधित्व करने के लिए:

<वाक्यविन्यास प्रकाश लैंग = जावा> पब्लिक क्लास एनिमल लिविंग थिंग का विस्तार करता है {

    निजी स्थान स्थान;
    निजी दोहरे ऊर्जा भंडार;

    पब्लिक बूलियन isHungry() {
        वापसी ऊर्जा भंडार <2.5;
    }
    सार्वजनिक शून्य खाना (भोजन खाना) {
        // भोजन ग्रहण करें
        एनर्जीरिजर्व += food.getCalories();
    }
    सार्वजनिक शून्य चाल (स्थान स्थान) {
        // नए स्थान पर जाएं
        यह.लोक = स्थान;
    }

} </वाक्यविन्यास हाइलाइट> उपरोक्त परिभाषा के साथ, कोई प्रकार की वस्तुएं बना सकता है Animal और उनके तरीकों को इस तरह बुलाओ:

<वाक्यविन्यास प्रकाश लैंग = जावा> सुअर = नया जानवर (); गाय = नया पशु (); अगर (thePig.isHungry ()) {

   दपिग.ईट (टेबलस्क्रैप्स);

} अगर (theCow.isHungry ()) {

   गाय खाओ (घास);

} theCow.moveTo(theBarn); </वाक्यविन्यास हाइलाइट> उपरोक्त उदाहरण में, वर्गAnimalएक वास्तविक जानवर के स्थान पर उपयोग किया जाने वाला एक अमूर्त है,LivingThingका एक और अमूर्तीकरण (इस मामले में एक सामान्यीकरण) हैAnimal.

यदि किसी को जानवरों के अधिक विभेदित पदानुक्रम की आवश्यकता होती है - अंतर करने के लिए, कहते हैं, जो उन लोगों से दूध प्रदान करते हैं जो अपने जीवन के अंत में मांस के अलावा कुछ भी नहीं प्रदान करते हैं - यह अमूर्तता का एक मध्यवर्ती स्तर है, शायद डेयरीएनिमल (गाय, बकरियां) जो अच्छा दूध देने के लिए उपयुक्त खाद्य पदार्थ खाएं, और मीटएनिमल (सूअर, बछड़े) जो सर्वोत्तम मांस-गुणवत्ता देने के लिए खाद्य पदार्थ खाएंगे।

इस तरह का एक अमूर्त भोजन के प्रकार को निर्दिष्ट करने के लिए एप्लिकेशन कोडर की आवश्यकता को दूर कर सकता है, इसलिए वे फीडिंग शेड्यूल पर ध्यान केंद्रित कर सकते हैं। दो वर्गों को वंशानुक्रम (कंप्यूटर विज्ञान) का उपयोग करके संबंधित किया जा सकता है या अकेले खड़े हो सकते हैं, और प्रोग्रामर दो प्रकारों के बीच बहुरूपता (कंप्यूटर विज्ञान) की अलग-अलग डिग्री को परिभाषित कर सकता है। ये सुविधाएं भाषाओं के बीच काफी भिन्न होती हैं, लेकिन सामान्य तौर पर प्रत्येक कुछ भी प्राप्त कर सकता है जो कि किसी अन्य के साथ संभव है। बहुत सारे ऑपरेशन ओवरलोड, डेटा प्रकार द्वारा डेटा प्रकार, संकलन-समय पर एक ही प्रभाव हो सकता है जैसा कि विरासत की किसी भी डिग्री या बहुरूपता को प्राप्त करने के अन्य साधनों के रूप में होता है। क्लास नोटेशन केवल कोडर की सुविधा है।

वस्तु-उन्मुख डिजाइन

कोडर के नियंत्रण में क्या सार करना है और क्या रखना है, इसके बारे में निर्णय वस्तु-उन्मुख डिजाइन और डोमेन विश्लेषण की प्रमुख चिंता बन जाते हैं - वास्तव में वास्तविक दुनिया में प्रासंगिक संबंधों का निर्धारण करना वस्तु-उन्मुख विश्लेषण और डिजाइन की चिंता है। वस्तु- उन्मुख विश्लेषण या विरासत विश्लेषण।

सामान्य तौर पर, उपयुक्त अमूर्तता का निर्धारण करने के लिए, किसी को कार्यक्षेत्र (डोमेन विश्लेषण) के बारे में कई छोटे निर्णय लेने चाहिए, यह निर्धारित करना चाहिए कि उसे किन अन्य प्रणालियों के साथ सहयोग करना चाहिए (विरासत विश्लेषण), फिर एक विस्तृत वस्तु-उन्मुख विश्लेषण करना चाहिए जो परियोजना समय और बजट के भीतर व्यक्त किया गया है। ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के रूप में बाधाएँ। हमारे सरल उदाहरण में, डोमेन बार्नयार्ड है, जीवित सूअर और गाय और उनकी खाने की आदतें विरासत की बाधाएँ हैं, विस्तृत विश्लेषण यह है कि कोडर्स के पास जानवरों को खिलाने के लिए लचीलापन होना चाहिए जो उपलब्ध है और इस प्रकार कोड करने का कोई कारण नहीं है वर्ग में ही भोजन का प्रकार, और डिजाइन एक साधारण पशु वर्ग है जिसमें सूअर और गाय समान कार्यों के उदाहरण हैं। DairyAnimal को अलग करने का निर्णय विस्तृत विश्लेषण को बदल देगा लेकिन डोमेन और विरासत विश्लेषण अपरिवर्तित रहेगा - इस प्रकार यह पूरी तरह से प्रोग्रामर के नियंत्रण में है, और इसे ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में अमूर्त कहा जाता है जो डोमेन या विरासत में अमूर्तता से अलग है। विश्लेषण।

विचार

जब प्रोग्रामिंग भाषाओं, औपचारिक तरीकों या अमूर्त व्याख्या के औपचारिक शब्दार्थ पर चर्चा की जाती है, तो अमूर्तन एक कम विस्तृत, लेकिन सुरक्षित, देखे गए कार्यक्रम व्यवहारों की परिभाषा पर विचार करने के कार्य को संदर्भित करता है। उदाहरण के लिए, निष्पादन के सभी मध्यवर्ती चरणों पर विचार करने के बजाय, कोई केवल प्रोग्राम निष्पादन के अंतिम परिणाम को देख सकता है। अमूर्तता को निष्पादन के एक ठोस (अधिक सटीक) मॉडल के रूप में परिभाषित किया गया है।

संपत्ति के संबंध में अमूर्त सटीक या वफादार हो सकता है यदि कोई संपत्ति के बारे में ठोस या अमूर्त मॉडल पर समान रूप से अच्छी तरह से एक प्रश्न का उत्तर दे सकता है। उदाहरण के लिए, यदि कोई यह जानना चाहता है कि केवल पूर्णांक +, -, × वाले गणितीय अभिव्यक्ति के मूल्यांकन का परिणाम मॉड्यूलर अंकगणित n के लायक है, तो उसे केवल सभी संक्रियाओं modulo n को निष्पादित करने की आवश्यकता है। (इस अमूर्तता का एक परिचित रूप नाइन को निकाल रहा है)।

सार, हालांकि, जरूरी नहीं कि सटीक हो, ठोस होना चाहिए। अर्थात्, उनसे ध्वनि उत्तर प्राप्त करना संभव होना चाहिए - भले ही अमूर्तता केवल अनिर्णीत समस्या का परिणाम हो। उदाहरण के लिए, एक कक्षा में छात्रों को उनकी न्यूनतम और अधिकतम आयु से अलग किया जा सकता है; यदि कोई पूछता है कि क्या कोई व्यक्ति उस वर्ग से संबंधित है, तो वह उस व्यक्ति की आयु की न्यूनतम और अधिकतम आयु के साथ तुलना कर सकता है; यदि उसकी आयु सीमा के बाहर है, तो कोई सुरक्षित रूप से उत्तर दे सकता है कि वह व्यक्ति उस वर्ग से संबंधित नहीं है; यदि ऐसा नहीं होता है, तो कोई केवल उत्तर दे सकता है कि मुझे नहीं पता।

प्रोग्रामिंग भाषा में शामिल अमूर्तता का स्तर इसकी समग्र उपयोगिता को प्रभावित कर सकता है। संज्ञानात्मक आयाम ढांचे में एक औपचारिकता में अमूर्त ढाल की अवधारणा शामिल है। यह रूपरेखा एक प्रोग्रामिंग भाषा के डिजाइनर को अमूर्तता और डिजाइन की अन्य विशेषताओं के बीच व्यापार-नापसंद का अध्ययन करने की अनुमति देती है, और कैसे अमूर्तता में परिवर्तन भाषा की उपयोगिता को प्रभावित करते हैं।

कंप्यूटर प्रोग्राम के साथ व्यवहार करते समय अमूर्त उपयोगी साबित हो सकते हैं, क्योंकि कंप्यूटर प्रोग्राम के गैर-तुच्छ गुण अनिवार्य रूप से अनिर्णीत समस्या हैं (राइस की प्रमेय देखें)। परिणामस्वरूप, कंप्यूटर प्रोग्राम के व्यवहार के बारे में जानकारी प्राप्त करने के लिए स्वचालित तरीकों को या तो समाप्ति को छोड़ना पड़ता है (कुछ अवसरों पर, वे विफल हो सकते हैं, क्रैश हो सकते हैं या कभी परिणाम नहीं निकल सकते हैं), सुदृढ़ता (वे गलत जानकारी प्रदान कर सकते हैं), या सटीकता ( वे उत्तर दे सकते हैं कि मुझे कुछ प्रश्नों के बारे में पता नहीं है)।

अमूर्तता अमूर्त व्याख्या की मूल अवधारणा है। मॉडल की जाँच आम तौर पर अध्ययन की गई प्रणालियों के अमूर्त संस्करणों पर होती है।

अमूर्तता के स्तर

कंप्यूटर विज्ञान आमतौर पर अमूर्तता के स्तर (या, कम सामान्यतः, परतें) प्रस्तुत करता है, जिसमें प्रत्येक स्तर समान जानकारी और प्रक्रियाओं के एक अलग मॉडल का प्रतिनिधित्व करता है, लेकिन अलग-अलग मात्रा में विस्तार के साथ। प्रत्येक स्तर अभिव्यक्ति की एक प्रणाली का उपयोग करता है जिसमें वस्तुओं और रचनाओं का एक अनूठा सेट शामिल होता है जो केवल एक विशेष डोमेन पर लागू होता है। ^[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). "Abstraction in Computer Science". Minds and Machines. 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). "Constructivism in computer science education". 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). "Computing as a discipline". 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). Lambda calculus with types. 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). "The Method of Levels of Abstraction". Minds and Machines. 18 (3): 303–329. doi:10.1007/s11023-008-9113-7. hdl:2299/2998. ISSN 0924-6495. S2CID 7522925.
↑ Spolsky, Joel. "The Law of Leaky Abstractions".
↑ "Abstract Methods and Classes". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.
↑ "Using an Interface as a Type". 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). "Adjudication rather than experience of data abstraction matters more in reducing errors in abstracting data in systematic reviews". Research Synthesis Methods. 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.

[1] Guttag, John V. (18 January 2013). Introduction to Computation and Programming Using Python (Spring 2013 ed.). Cambridge, Massachusetts: The MIT Press. ISBN 9780262519632.

[:1-2] 2.0 ^2.1 Colburn, Timothy; Shute, Gary (5 June 2007). "Abstraction in Computer Science". Minds and Machines. 17 (2): 169–184. doi:10.1007/s11023-007-9061-7. ISSN 0924-6495. S2CID 5927969.

[:0-3] 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.

[4] Ben-Ari, Mordechai (1 March 1998). "Constructivism in computer science education". ACM SIGCSE Bulletin. 30 (1): 257, 257–261. doi:10.1145/274790.274308. ISSN 0097-8418.

[5] Comer, D. E.; Gries, David; Mulder, Michael C.; Tucker, Allen; Turner, A. Joe; Young, Paul R. /Denning (1 January 1989). "Computing as a discipline". Communications of the ACM. 32 (1): 9–23. doi:10.1145/63238.63239. ISSN 0001-0782. S2CID 723103.

[6] 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.

[7] Barendregt, Hendrik Pieter (1984). The lambda calculus : its syntax and semantics (Revised ed.). Amsterdam: North-Holland. ISBN 0444867481. OCLC 10559084.

[8] Barendregt, Hendrik Pieter (2013). Lambda calculus with types. Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic. Cambridge, UK: Cambridge University Press. ISBN 9780521766142. OCLC 852197712.

[9] 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.

[10] Floridi, Luciano (September 2008). "The Method of Levels of Abstraction". Minds and Machines. 18 (3): 303–329. doi:10.1007/s11023-008-9113-7. hdl:2299/2998. ISSN 0924-6495. S2CID 7522925.

[11] Spolsky, Joel. "The Law of Leaky Abstractions".

[Oracle_Java_abstract-12] "Abstract Methods and Classes". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.

[Oracle_Java_interface-13] "Using an Interface as a Type". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.

[14] E, Jian‐Yu; Saldanha, Ian J.; Canner, Joseph; Schmid, Christopher H.; Le, Jimmy T.; Li, Tianjing (2020). "Adjudication rather than experience of data abstraction matters more in reducing errors in abstracting data in systematic reviews". Research Synthesis Methods. 11 (3): 354–362. doi:10.1002/jrsm.1396. ISSN 1759-2879. PMID 31955502. S2CID 210829764.

[15] Luciano Floridi, Levellism and the Method of Abstraction IEG – Research Report 22.11.04

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]