अमूर्तता क्या है? [बन्द है]

Question

क्या प्रोग्रामर द्वारा उपयोग की जाने वाली प्रोग्रामिंग अमूर्तता की परिभाषा पर आम तौर पर सहमति है ? [ध्यान दें, प्रोग्रामिंग एब्स्ट्रैक्शन शब्द "एब्सट्रैक्शन" के लिए शब्दकोष परिभाषाओं के साथ भ्रमित नहीं होना है? क्या कोई असंदिग्ध है, या गणितीय परिभाषा भी है? सार के कुछ स्पष्ट उदाहरण क्या हैं?

Comments

..और यह साबित करने के लिए मजबूर किया जा रहा है कि मैं एक रोबोट नहीं हूँ जब यह पोस्ट करने से पता चलता है कि मैं वास्तव में बहुत ज्यादा माँग रहा हूँ :)

— mlvljr

"गणितीय" से आपका क्या तात्पर्य है? मैं वास्तव में एक गणितीय अवधारणा के रूप में अमूर्तता के बारे में नहीं सोचूंगा।

— फिशटोस्टर

@mlvljr: मुझे क्षमा करें, मुझे अभी भी यकीन नहीं है कि मैं अनुसरण करूंगा। अमूर्तता सिर्फ कुछ से निपटने का एक सरल तरीका प्रदान करने का अभ्यास है। मैं नहीं देखता कि कैसे औपचारिक उपकरण / विधियों का इससे कोई लेना-देना है।

— फिशटोस्टर

@mlvljr, क्या आप सभी प्रोग्रामिंग अर्क को कवर करने के लिए एक गणित उदाहरण, या एक गणित चाहते हैं। मुझे नहीं लगता कि बाद का अस्तित्व है।

— सी। रॉस

Perhpas cstheory.stackexchange.com इस प्रश्न के लिए सही जगह है

— कॉनरेड फ्रीक्स

Answer 1

"क्या आप परिभाषित कर सकते हैं कि प्रोग्रामिंग एब्स्ट्रैक्शन कम या ज्यादा गणितीय है?" कोई नहीं।" अमूर्त एक गणितीय अवधारणा नहीं है। यह किसी को नींबू के रंग को गणितीय रूप से समझाने के लिए कहने जैसा होगा।

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

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

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग अमूर्त और परिवारों या उनमें से समूहों की अवधारणा पर बनाया गया है। अच्छा OOP का अर्थ है विस्तार के उपयुक्त स्तर पर अच्छे सार चुनना जो आपके प्रोग्राम के डोमेन में कोई मायने रखता है और "लीक" नहीं है। पूर्व का मतलब है कि एक माउस को एक ऑब्जेक्ट के रूप में वर्गीकृत करना जो एक इच्छुक विमान पर रोल नहीं करेगा, एक ऐसे अनुप्रयोग के लिए कोई मतलब नहीं है जो कंप्यूटर उपकरण का आविष्कार करता है, लेकिन यह एक भौतिकी सिम्युलेटर के लिए समझ में आ सकता है। उत्तरार्द्ध का मतलब है कि आपको "बॉक्सिंग में अपने आप को" एक पदानुक्रम से बचने की कोशिश करनी चाहिए जो किसी प्रकार की वस्तुओं के लिए समझ में नहीं आता है। उदाहरण के लिए, ऊपर मेरे पदानुक्रम में, क्या हम निश्चित हैं कि सभीकंप्यूटर बाह्य उपकरणों को बिजली द्वारा संचालित किया जाता है? एक लेखनी के बारे में क्या? अगर हम एक स्टाइलस को "परिधीय" श्रेणी में समूहित करना चाहते हैं, तो हमें एक समस्या होगी, क्योंकि यह बिजली का उपयोग नहीं करता है, और हमने कंप्यूटर बाह्य उपकरणों को उन वस्तुओं के रूप में परिभाषित किया है जो बिजली का उपयोग करते हैं। वृत्त-अंडाकार समस्या इस पहेली का सबसे अच्छा ज्ञात उदाहरण है।

Comments

मुझे लगता है कि मैं देख रहा हूं; आप विशेष रूप से एक विधि या कार्य को एक सार तरीके से संदर्भित करने के बारे में बात कर रहे हैं, अर्थात इसके अनुबंध के अनुसार इसके कार्यान्वयन के विपरीत। आपके कथन सही हैं, और यह शब्द का पूरी तरह से मान्य उपयोग है; एक विधि कॉल कुछ प्रकार के ठोस व्यवहार का एक अमूर्त हिस्सा है।

— nlawalker

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

— पिलमंचर

एक नींबू का रंग, गणितीय रूप से, लगभग 570 एनएम के तरंग दैर्ध्य के साथ हल्का होता है।

— एरिक

@ एरिक मैं ऐसा लिखने जा रहा था। बाह!

— गैरी रोवे

@ एरिक यह भौतिकी है, गणित नहीं :) गणित "प्रकाश" जैसी अवधारणाओं के बारे में कुछ नहीं जानता है। प्रकाश अनुभवजन्य है; गणित नहीं है।

— एंड्रेस एफ।

Answer 2

मैं स्पष्ट रूप से अधिकांश उत्तरों से असहमत हूं।

यह मेरा जवाब है:

दो सेटों जी और एच को देखते हुए , उनके बीच एक गैल्विस कनेक्शन (अल्फा, बीटा) को परिभाषित किया जा सकता है, और एक को दूसरे का संघटन कहा जा सकता है; कनेक्शन को उल्टा करें, और एक दूसरे का अमूर्त हिस्सा है। फ़ंक्शंस एक संकेतन समारोह और एक अमूर्त फ़ंक्शन हैं।

यह कंप्यूटर कार्यक्रमों की अमूर्त व्याख्या के सिद्धांत से है, जो आम तौर पर एक स्थिर विश्लेषण दृष्टिकोण है।

Comments

ठीक है, आपको व्यावसायिकता के लिए एक स्वर्ण सितारा मिला है :)

— माइक डनलैवी

@ मायके: याय? :-)

— पॉल नाथन

आह, और क्या कोई उदाहरण हो सकता है?

— 9

@mlvljr: di.ens.fr/~cousot/AI astree.ens.fr डेटा का एक स्केच प्रदान करता है।

— पॉल नाथन

आमिर: यह स्थैतिक विश्लेषण की दुनिया से अमूर्तता की तकनीकी परिभाषा है।

— पॉल नाथन

Answer 3

अमूर्त पर अधिक ध्यान केंद्रित है Whatऔर कम पर है How। या आप कह सकते हैं, केवल उन चीजों को जानें जिनकी आपको आवश्यकता है, और बस अन्य सभी सेवाओं के लिए प्रदाता पर भरोसा करें। यह कभी-कभी सेवा प्रदाता की पहचान भी छिपा देता है।

उदाहरण के लिए, यह साइट सवाल पूछने और उनका जवाब देने के लिए एक प्रणाली प्रदान करती है। यहां लगभग हर कोई जानता है कि इस साइट पर पूछने, जवाब देने, मतदान करने और अन्य चीजों के लिए क्या प्रक्रियाएं हैं। लेकिन बहुत कम लोग जानते हैं कि अंतर्निहित प्रौद्योगिकियां क्या हैं। जैसे कि साइट ASP.net mvc या पायथन के साथ विकसित की गई थी, चाहे यह विंडोज या लिनक्स सर्वर आदि पर चलती हो, क्योंकि यह हमारे किसी भी व्यवसाय से नहीं है। इसलिए, यह साइट हमें सेवा प्रदान करने के लिए अपने अंतर्निहित तंत्र पर एक अमूर्त परत रख रही है।

कुछ अन्य उदाहरण:

• एक कार अपने सभी तंत्रों को छुपाती है, लेकिन उसे चलाने, उसे ईंधन भरने और उसे मालिक बनाए रखने का एक तरीका प्रदान करती है।

• कोई भी API अन्य प्रोग्रामरों को सेवा प्रदान करने के लिए अपने सभी कार्यान्वयन विवरणों को छुपाता है।

• OOP में एक वर्ग अपने निजी सदस्यों को छुपाता है और सार्वजनिक सदस्यों को लागू करने के लिए सार्वजनिक सदस्यों को कॉल करने की सेवा प्रदान करता है।

• एक के प्रकार की एक वस्तु का उपयोग करते समय Interfaceया एक abstract classजावा या C ++, वास्तविक कार्यान्वयन छिपा हुआ है। और सिर्फ छिपा हुआ नहीं है, घोषित तरीकों के कार्यान्वयन Interfaceभी विभिन्न कार्यान्वित / विरासत वाले वर्गों में भिन्न होने की संभावना है। लेकिन जैसा कि आप एक ही सेवा हो रही है, बस परेशान नहीं है Howयह लागू किया गया है और वास्तव में Who/ Whatसेवा प्रदान कर रहा है।

• पहचान छिपाना : वाक्य के लिए "मुझे पता है कि सैम कंप्यूटर प्रोग्राम लिख सकता है।" अमूर्त हो सकता है- "सैम एक प्रोग्रामर है। प्रोग्रामर कंप्यूटर प्रोग्राम लिखना जानते हैं।" दूसरे कथन में, व्यक्ति महत्वपूर्ण नहीं है। लेकिन प्रोग्रामिंग करने की उसकी क्षमता महत्वपूर्ण है।

Comments

तो क्यों न इसे "सटीक विनिर्देश" कहा जाए, जिसे btw?

— 18

Satori बिट, भी के लिए +1

— mlvljr

@mlvljr Howहमेशा Whatएस को समझने में मददगार होता है । तो, यह अमूर्तता के साथ मिश्रित किया जा सकता है।

— गुलशन

Answer 4

एक प्रोग्रामिंग अमूर्त एक समस्या का एक सरलीकृत मॉडल है।

उदाहरण के लिए, टीसीपी / आईपी कनेक्शन डेटा भेजने पर एक अमूर्त है। आप केवल एक आईपी पता और एक पोर्ट नंबर शामिल करते हैं और इसे एपीआई में भेज देते हैं। आप तारों, संकेतों, संदेश प्रारूपों और विफलताओं के सभी विवरणों से चिंतित नहीं हैं।

Comments

अहा! यहाँ एक सरलीकृत मॉडल क्या है ? लीक पहेली, btw याद है ? :)

— mlvljr

Answer 5

एक अमूर्त सिर्फ एक प्रमेय का प्रोग्रामिंग संस्करण है।

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

कार्यात्मक प्रोग्रामिंग में, गणितीय कथन के रूप में एक कार्यक्रम का विचार बहुत मजबूत होता है, और अक्सर प्रकार प्रणाली (हास्केल, एफ #, या OCAML की तरह एक मजबूत, वैधानिक रूप से टाइप की गई भाषा में) का उपयोग साक्ष्यों के माध्यम से प्रमेय परीक्षण के लिए किया जा सकता है।

उदाहरण के लिए: मान लें कि हमारे पास आदिम संचालन के रूप में जोड़ और समानता की जाँच है, और पूर्णांक और बूलियन आदिम डेटा प्रकार के रूप में हैं। ये हमारे स्वयंसिद्ध हैं। तो हम कह सकते हैं कि 1 + 3 == 2 + 2एक प्रमेय है, तो जोड़ और पूर्णांक और समानता के नियमों का उपयोग करके देखें कि क्या यह एक सच्चा कथन है।

अब मान लें कि हम गुणा करना चाहते हैं, और हमारी आदिमता (संक्षिप्तता के लिए) में एक लूपिंग निर्माण और प्रतीकात्मक संदर्भ निर्दिष्ट करने का साधन शामिल है। हम सुझाव दे सकते हैं कि

ref x (*) y := loop y times {x +}) 0

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

मैं अपने टाइप सिस्टम को भी देख सकता हूँ। (*) का एक प्रकार है int -> int -> int। यह 2 इन्ट्स लेता है और एक इंट को आउटपुट करता है। जोड़ में एक प्रकार का int -> int -> int होता है इसलिए 0 + (बाकी) एक int में लंबे समय तक (बाकी) परिणाम रखता है। मेरा लूप सभी प्रकार की चीजें कर सकता है, लेकिन मैं कह रहा हूं कि यह क्यूरेटेड फंक्शंस की एक श्रृंखला का उत्पादन करता है जैसे कि (x + (x + (x ... + 0)) परिणाम। उस जोड़ श्रृंखला का रूप सिर्फ (int -> (int -> (int ... - int))) है, इसलिए मुझे पता है कि मेरा अंतिम आउटपुट एक int होगा। तो मेरे प्रकार के सिस्टम ने मेरे अन्य प्रमाण के परिणामों को पकड़ लिया!

कई वर्षों, कई प्रोग्रामर, और कोड की कई पंक्तियों पर इस तरह के विचार को लिखें, और आपके पास आधुनिक प्रोग्रामिंग भाषाएं हैं: आदिम और "सिद्ध" कोड सार के विशाल पुस्तकालयों का हार्दिक सेट।

Answer 6

क्या विकिपीडिया का जवाब काफी अच्छा होगा? http://en.wikipedia.org/wiki/Abstraction_%28programming%29

कंप्यूटर विज्ञान में, अमूर्तता का तंत्र और अभ्यास विवरणों को कम करता है और कारकों का विवरण देता है ताकि व्यक्ति एक समय में कुछ अवधारणाओं पर ध्यान केंद्रित कर सके।

Comments

और तब एक अमूर्त चीज का उदाहरण क्या होगा?

— mlvljr

@mlvljr: यदि आप विकिपीडिया लेख पढ़ते हैं, तो आप कुछ देखेंगे।

— जॉन फिशर

दुख की बात है, मैं बहुत ज्यादा यकीन है कि वे बहुत सार हो जाएगा ..

— mlvljr

Answer 7

खैर, गणितीय रूप से, "पूर्णांक" एक अमूर्त है। और जब आप सभी पूर्णांकों के लिए उस x + y = y + x जैसे औपचारिक साक्ष्य करते हैं, तो आप 3 या 4 जैसी विशिष्ट संख्याओं के बजाय अमूर्त "पूर्णांक" के साथ काम कर रहे हैं। यही बात सॉफ्टवेयर विकास में भी होती है, जब आप बातचीत करते हैं। रजिस्टर और स्मृति स्थानों के ऊपर एक स्तर पर मशीन। आप ज्यादातर मामलों में अधिक अमूर्त स्तर पर अधिक शक्तिशाली विचार सोच सकते हैं।

Comments

का उपयोग नहीं करेंगे और IInt add(IInt a, IInt b);सबरूटीन एक कार्यक्रम में जहां पहले से पता है कि aऔर bहो जाएगा, कहना Int128: IIntएक कम या ज्यादा अच्छा उदाहरण? - यदि आपके पास अपना कोड टुकड़ा है, तो उसे क्या करना चाहिए, यह जानते हुए (साबित करने में सक्षम) यह आपकी ज़रूरत की चीज़ और उसी समय (और दूसरी ओर) आपको वह कर देगा जो आप ठीक से करते हैं आवश्यकता के बिना इसे जानने के साथ (अन्य संदर्भों में भी उस चीज़ का उपयोग करने की क्षमता के साथ)?

— 17

क्षमा करें, लेकिन मैं आपके प्रश्न को नहीं समझ सकता।

— केट ग्रेगोरी

ठीक है, मान लीजिए, आप एक प्रोग्राम लिख रहे हैं जिसमें 2 से 3 जोड़ना है। आप एक add(int, int)सबरूटीन / फ़ंक्शन को कॉल करके ऐसा करते हैं । बस return 2 + 3;इस मामले में यह पर्याप्त होगा । और आपको एक अधिक "सार्वभौमिक" दिनचर्या का उपयोग क्यों करना चाहिए ( return a + b;अर्थात किसी भी वास्तविक a और bआपूर्ति किए गए मापदंडों पर काम कर रहा है , और इस प्रकार वास्तव में उनके मूल्यों से अमूर्त है) - यही मेरा (बयानबाजी) ऊपर सवाल था। आशा है कि अब यह थोड़ा और स्पष्ट हो जाएगा।

— mlvjjr

मेरी पहली टिप्पणी सुंदर "आत्म-

— प्रेरित

Answer 8

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

मुझे एक पिवेट की अनुमति दें ...

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

Comments

अमूर्त के बारे में सोचकर "बहुत सुंदर होना स्पष्ट रूप से माना जाता है (या, और भी अधिक, सूखी (गणितीय) शर्तों में वर्णित)" (सबसे पहले और कम से कम) यह समझने में मदद नहीं करता है कि यह क्या है और (दूसरी बात) इसकी तकनीक विकसित करना आवेदन और (डरावनी!) मूल्यांकन [कैसे और किस तरह से दिए गए कोड सार है]।

— mlvljr

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

— जेसन बेकर

@ जैसन बेकर हमारी अमूर्त तकनीकों को प्रभावी ढंग से उपयोग करने के लिए पर्याप्त ठोस होने दें ...

— mlvjjr

@ जेसन: "यदि एक स्थान पर बदलाव से आपको कहीं और कई बदलाव करने पड़ते हैं, तो आपका सार खराब है।" मैं तुम्हारे साथ वहाँ हूँ। मुझे लगता है कि वे बुरे लोगों से घिरे हुए हैं।

— माइक डनलैवी

ऐसा लगता है कि आपने एक ऐसे स्थान पर काम किया है जहाँ देवताओं के भव्य दर्शन हुए थे, और टीम को ध्यान में रखते हुए एक मजबूत बॉस नहीं था। जब मैं अपने आप को इस तरह के माहौल में पाता हूं कि मैं दूसरी नौकरी तलाशने लगता हूं (प्रोजेक्ट बजट हमेशा खत्म हो जाता है, या छोटी कंपनी => दिवालिया)। मैंने हाल ही में एक ट्वीट देखा: 'स्पेगेटी कोड' बनाम 'लैसनैना कोड', बाद वाला तब है जब बहुत सारी परतें हैं।

— यजॉर्ग

Answer 9

मुझे लगता है कि आपको लीक से हटकर उपयोगी सार पर मेरा एक ब्लॉग पोस्ट मिल सकता है। यहाँ प्रासंगिक पृष्ठभूमि है:

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

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

एब्सट्रैक्शन एन्कैप्सुलेशन और मॉड्युलैरिटी से संबंधित है, और इन अवधारणाओं को अक्सर गलत समझा जाता है।

में Listउदाहरण के लिए, कैप्सूलीकरण किसी लिंक किए गए-सूची के कार्यान्वयन विवरण छिपाने के लिए किया जा सकता है; उदाहरण के लिए, ऑब्जेक्ट-ओरिएंटेड भाषा में, आप nextऔर previousपॉइंटर्स को निजी बना सकते हैं , जहाँ केवल इन क्षेत्रों में सूची कार्यान्वयन की अनुमति है।

गर्भपात के लिए एनकैप्सुलेशन पर्याप्त नहीं है, क्योंकि यह जरूरी नहीं है कि आपके पास निर्माणों की एक नई या अलग अवधारणा है। यदि सभी Listवर्ग ने आपको ' getNext' / ' setNext' स्टाइल एक्सेसर मेथड दिया था, तो यह कार्यान्वयन विवरणों से आपसे अलग हो जाएगा (उदाहरण के लिए, आपने फ़ील्ड को ' prev' या ' previous' नाम दिया था? इसका स्थैतिक प्रकार क्या था?), लेकिन यह अमूर्तता की बहुत कम डिग्री होगी।

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

जानकारी छिपाना एन्कैप्सुलेशन द्वारा सहायता प्राप्त है (ताकि आपका कोड अस्थिर कार्यान्वयन विवरणों पर निर्भर न हो), लेकिन प्रतिरूपकता के लिए एनकैप्सुलेशन आवश्यक नहीं है। उदाहरण के लिए, यदि आप एक को लागू कर सकते Listसी में संरचना, 'उजागर next' और ' prevदुनिया के लिए' संकेत दिए गए, लेकिन यह भी एक इंटरफेस प्रदान, युक्त initList(), addToList()औरremoveFromList()कार्य करता है। बशर्ते कि इंटरफ़ेस के नियमों का पालन किया जाता है, आप गारंटी दे सकते हैं कि कुछ गुण हमेशा पकड़ लेंगे, जैसे कि डेटा-संरचना हमेशा एक मान्य स्थिति में है। [उदाहरण के लिए पारनस का क्लासिक पेपर, उदाहरण के लिए, विधानसभा में एक उदाहरण के साथ लिखा गया था। इंटरफ़ेस एक अनुबंध और डिजाइन के बारे में संचार का एक रूप है, यह जरूरी नहीं कि यंत्रवत् जाँच की जानी चाहिए, हालांकि यही आज के लिए निर्भर है।]

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

• यदि n ^ 3 एल्गोरिथ्म "अच्छी तरह से समझाया गया है" तो यह अभी भी एक बेहतर एन लॉग एन एल्गोरिथम से भी बदतर प्रदर्शन करेगा।

• यदि कोई इंटरफ़ेस किसी विशिष्ट ऑपरेटिंग सिस्टम पर जाता है, तो मॉड्यूलर डिज़ाइन के लाभों में से किसी को भी महसूस नहीं किया जाएगा, जब एक वीडियो गेम को विंडोज से आईपैड में पोर्ट करने की आवश्यकता होती है।

• यदि बनाई गई अमूर्तता बहुत सारे अशुभ विवरणों को उजागर करती है, तो यह अपने स्वयं के संचालन के साथ एक नया निर्माण करने में विफल रहेगी: यह बस उसी चीज के लिए एक और नाम होगा।

Comments

खैर, ऐसा लगता है कि मैं वास्तव में क्या चाहता था (कुछ सामान्य-सा / उदाहरण-आधारित "किराए" पर "मॉड्यूलर == सार == अच्छा == आप-कभी-अनुमान-यह-बस-संघर्ष" दृश्य) , धन्यवाद (अभी भी पढ़ रहा

— हूं

और यहाँ मेरे आगामी उत्तर से (मेरे स्वयं के प्रश्न के लिए) एक उत्तेजक आदर्श वाक्य है "जब मन कमजोर होता है तो रिसाव होता है";)

— mlvljr

Answer 10

ठीक है, मुझे लगता है कि मुझे पता चल गया है कि आप क्या पूछ रहे हैं: "एक गणितीय रूप से कठोर परिभाषा क्या है" एक अमूर्त। "

अगर ऐसा है, तो मुझे लगता है कि आप भाग्य से बाहर हैं- 'अमूर्त' एक सॉफ्टवेयर आर्किटेक्चर / डिज़ाइन शब्द है, और इसका कोई गणितीय समर्थन नहीं है जहाँ तक मुझे पता है (शायद कोई बेहतर सैद्धांतिक सीएस में निपुण मुझे सही करेगा यहाँ), "युग्मन" या "सूचना छिपाने" की तुलना में किसी भी अन्य की गणितीय परिभाषा है।

Answer 11

अमूर्तता तब होती है जब आप उन विवरणों को अनदेखा कर देते हैं जिन्हें प्रासंगिक समझा जाता है।

अमूर्तता में एनकैप्सुलेशन, सूचना छिपाना और सामान्यीकरण शामिल हैं। यह उपमाओं, रूपकों या अनुमानों को शामिल नहीं करता है।

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

अमूर्तता कुछ ऐसा नहीं है जिसे आप घोषित करते हैं, यह कुछ ऐसा है जो आप करते हैं ।

Comments

+1, "मैं अमूर्तता करता हूं!" टी-शर्ट के लिए अच्छा होगा;) मॉर्फिज़्म पर लिंक के लिए धन्यवाद (हालांकि) यह सीधे पॉली का उल्लेख नहीं करता है - एक दर्जन से अधिक अन्य लोगों में से एक;)।

— mlvljr

Answer 12

किसी अन्य व्यक्ति को इसे समझाने के तरीके के रूप में, मैं परिणामों के पीछे से दूसरे रास्ते पर जाऊंगा:

कंप्यूटर प्रोग्रामिंग में अमूर्तता इस बात को सामान्य बनाने का कार्य है कि एक से अधिक समान चीजों को आम तौर पर एक ही माना जा सकता है और उसी को संभाला जा सकता है।

यदि आप उस पर विस्तार करना चाहते हैं तो आप जोड़ सकते हैं:

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

इसके अलावा, मुझे लगता है कि आपको उदाहरणों में शुरू करना होगा ...

Answer 13

आप बॉब मार्टिन के कुछ मैट्रिक्स की जाँच कर सकते हैं

http://en.wikipedia.org/wiki/Software_package_metrics

उन्होंने कहा, मुझे नहीं लगता कि उनका "एब्सट्रेसी" भी आपके जैसा ही है। उसका एक और उपाय है "इंटरफेस पर अमल की कमी" जिसका अर्थ है इंटरफेस / अमूर्त वर्गों का उपयोग। मुख्य अनुक्रम से अस्थिरता और दूरी शायद आप जिस चीज की तलाश कर रहे हैं उसमें अधिक खेलते हैं।

Comments

हाँ, उस कागज को याद रखें। अंकल बॉब भीड़ को ऊर्जावान बनाने और ओओ के यांत्रिकी में रुचि रखने वाले लोगों के लिए शानदार हैं।

— mlvjjr

अजीब बात है, मैं (एक ही बार में) को भूल गया :)

— mlvljr

Answer 14

मेरियम-वेबस्टर एक विशेषण के रूप में सार को परिभाषित करता है: किसी भी विशिष्ट उदाहरण से अलग किया गया।

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

हालांकि कई बार, गणितीय निर्माणों के संदर्भ में सार को परिभाषित किया जाता है। ऐसा शायद इसलिए है क्योंकि वे विज्ञान और इंजीनियरिंग में अक्सर उपयोग किए जाते हैं।

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

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

जैसा कि दूसरों ने कहा है, यह एक सरलीकृत मॉडल है। यह एक उपकरण है जिसका उपयोग जटिल प्रणालियों को बेहतर ढंग से समझने के लिए किया जाता है।

Comments

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

— 20

आप कोई मतलब नहीं कर रहे हैं। एक वास्तविक प्रणाली के डिजाइन पर संकेत प्रदान करना अमूर्तता का उद्देश्य नहीं है। यदि आपको कुछ भी पता नहीं है कि क्या मॉडलिंग की जा रही है, तो यह हल करने के लिए अमूर्त के लिए कोई समस्या नहीं है।

— whatsisname

मैं वास्तविक दुनिया की वस्तुओं के सार को दूर करने के बारे में बात कर रहा था जो सॉफ्टवेयर उस सॉफ्टवेयर को बनाने की प्रक्रिया से निपटेगा। एक वास्तविक दुनिया की इकाई के सॉफ्टवेयर (सॉफ्टवेयर) का उपयोग करके (फिर से) उस वास्तविक दुनिया की वस्तु का मतलब नहीं था (यह "सॉफ्टवेयर सिस्टम" के रूप में "सिस्टम" है, लेकिन इस प्रकार सिस्टम के डिजाइन पर कुछ सहायक संकेत प्रदान करता है) मेरी टिप्पणी ऊपर)।

— mlvljr

Answer 15

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

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

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

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

Comments

यदि यह टपका हुआ है, तो यह स्पष्ट रूप से एक अमूर्त नहीं है ... पर्याप्त, चलो ईमानदार रहें।

— mlvljr

@mlvljr कंप्यूटर्स गणित की समस्याएँ नहीं हैं, दुख की बात है, इसलिए आपको लीक के कुछ स्तर के लिए अनुमति देनी होगी। यदि और कुछ नहीं, तो यह तथ्य कि गणना एक भौतिक उपकरण पर की जा रही है, इसका मतलब है कि समस्याओं के दायरे के खिलाफ कुछ बाधाओं को मॉडल किया जा सकता है। तकनीकी रूप से, अपूर्णता प्रमेयों का अर्थ है कि कुछ चीजें गणितीय प्रणालियों के बारे में आंतरिक रूप से सिद्ध नहीं की जा सकती हैं, इसलिए यहां तक ​​कि गणित में "टपका हुआ सार" है।

— 19x पर कोडेक्सआर्कनम

आप हमेशा एक ऐसी स्थिति पा सकते हैं जहां एक अमूर्त रिसाव होगा। एक सही अमूर्तता जैसी कोई चीज नहीं है। यह बस एक बात है कि यह कितना लीक होता है और आप इसके साथ रह सकते हैं या नहीं।

— दिमा

@CodexArcanum 1. एक रूटीन int(MAX_INT_SIZE / 2-1) से कम लेने वाला और दूसरा जो दो बार ज्यादा होता है: int f(int a) { return a*2; }2. एक "हैंडलर" void (*) (void)जिसे प्रोटोटाइप कहा जाता है, जब ... उहम्म् के अनुसार इसे बुलाया जाना चाहिए। कॉलर का अनुबंध - दोनों अमूर्तताओं का प्रतिनिधित्व करते हैं (1 - इसके कार्यान्वयन के विवरण पर (जो हमने प्रदान किया है, लेकिन जो उन लोगों के लिए सुलभ नहीं होगा जिनके पास स्रोत कोड तक कोई पहुंच नहीं है), 2-- ओवर हैंडलर क्या है करता है (ध्यान दें, हालांकि यह उस व्यक्ति को जाना जाता है जिसने हैंडलर को सौंपा है)) और लीक न करें

— mlvljr

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

— कोडेक्सआर्कनम

Answer 16

एक तरह से मैं लोगों को इसका वर्णन करने की कोशिश करता हूं, हो सकता है कि यह सबसे अच्छा तरीका न हो

एक प्रोग्राम पर विचार करें जो 2 + 2 जोड़ता है और 4 आउटपुट करता है

एक प्रोग्राम पर विचार करें जो उपयोगकर्ता द्वारा दो नंबर इनपुट जोड़ता है, x + y = z

कौन सा अधिक उपयोगी और सामान्य है?

Comments

केट ग्रेगोरी के जवाब के बारे में मेरी टिप्पणी लगभग यही थी। ;) दिलचस्प बात यह है, जबकि कम सामान्य कार्यक्रम अधिक सामान्य एक का उपयोग कर सकता है, एक उपयोगकर्ता प्रदान करता है जिसने दूसरे के साथ पहले एक का अनुरोध किया है, संभवतः काउंटर-उपयोगी होगा ...

— mlvljr

Answer 17

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

एब्स्ट्रक्शन को एक साथ जोड़कर बड़ा एब्सट्रैक्ट भी बनाया जा सकता है। उदाहरण के लिए, फ़ंक्शंस को एक कक्षा में एक साथ रखा जा सकता है, प्रोग्राम बनाने के लिए कक्षाओं को एक साथ रखा जा सकता है, प्रोग्राम को एक डिस्ट्रीब्यूटेड फॉर्म बनाने के लिए एक साथ रखा जा सकता है, आदि।

Comments

कोड को कॉल save_to_databaseकरने के बारे में चिंता नहीं करनी चाहिए कि डेटा को कैसे बचाया जाता है, जब तक / क्योंकि आपने उस कार्यान्वयन को चुना है जिसकी आपको आवश्यकता है ! यानी वैसे भी (कोड के कुछ टुकड़ों के लिए "अमूर्त" रिश्तेदार "प्रदान करने के लिए एक जगह होगी) वैसे भी, यह सिर्फ विवेकपूर्ण तरीके से चुनने की बात है - आसान" मन के परिवर्तन "के लिए प्रदान करना, आदि

— mlvljr

Answer 18

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

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

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

अमूर्तता के कुछ फायदे हैं:

• एक बड़ी समस्या को प्रबंधनीय टुकड़ों में विभाजित करने की अनुमति देता है। डेटाबेस में किसी व्यक्ति के रिकॉर्ड जोड़ते समय, आप डेटाबेस पर इंडेक्स पेड़ों को डालने और संतुलित करने के साथ खिलवाड़ नहीं करना चाहते। हो सकता है कि यह कार्य किसी बिंदु पर किया गया हो, लेकिन अब इसे समाप्त कर दिया गया है और आपको इसके बारे में चिंता करने की आवश्यकता नहीं है।

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

• ऐसे लोगों को अनुमति देता है जिनके पास ऐसा करने के लिए जटिल कार्य करने के लिए आवश्यक ज्ञान नहीं है। मेरी माँ अपने फेसबुक को अपडेट कर सकती है और देश भर के लोगों को वह जान सकती है। एक साधारण वेब इंटरफेस के लिए एक पागल जटिल प्रणाली के अमूर्त बिना, कोई रास्ता नहीं है कि वह कुछ ऐसा ही करने के लिए शुरू करने में सक्षम होगा (और न ही मैं इस मामले के लिए होगा)।

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

Answer 19

परोक्ष का एक अतिरिक्त स्तर।

आप परवाह नहीं करना चाहते हैं कि आप जिस वस्तु का उपयोग कर रहे हैं वह एक Catया एक है Dog, इसलिए आप सही makeNoise()फ़ंक्शन खोजने के लिए वर्चुअल फ़ंक्शन तालिका के माध्यम से जाते हैं ।

मुझे यकीन है कि यह 'कम' और 'उच्च' स्तरों पर भी लागू किया जा सकता है - एक संकलक के बारे में सोचें जो किसी दिए गए प्रोसेसर के लिए उपयोग करने के लिए सही निर्देश ढूंढ रहा है या Monadसब कुछ returnऔर कॉल करके कम्प्यूटेशनल प्रभाव पर हास्केल का सार >>=।

Answer 20

यह एक ऐसी चीज है जिसे मैं वास्तव में लंबे समय तक ब्लॉग करना चाहता था, लेकिन मुझे यह कभी नहीं मिला। सौभाग्य से, मैं एक प्रतिनिधि ज़ोंबी हूं और यहां तक ​​कि एक इनाम भी है। मेरा पद लंबा नहीं निकला , लेकिन यहाँ सार है:

प्रोग्रामिंग में अमूर्त किसी दिए गए संदर्भ के भीतर किसी वस्तु के सार को समझने के बारे में है।

[...]

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

उम्मीद है की वो मदद करदे।

Comments

+1, हाँ, यह विषय वास्तव में हम में से बहुत से लोगों को परेशान करता है;) मुझे आशा है कि (अंत में) चर्चा के लिए कुछ और रुचि को भड़काने के लिए अपने स्वयं के कुछ बिंदुओं के साथ आपके उत्तर को पूरक करूंगा।

— mlvljr

Answer 21

यहाँ, एक जवाब नहीं है:

प्रोग्रामिंग में दूर रहने का नाटक कर रहे हैं आप अब विवरण के बारे में परवाह नहीं करते हैं, जबकि वास्तव में आप करते हैं और आपको हर समय उनकी परवाह करनी चाहिए। यह मूल रूप से ढोंग है।

Comments

+1, लेकिन हमेशा ऐसा नहीं लगता कि मैं (वास्तव में अनावश्यक विवरणों के बारे में सोचता हूं :))। प्रारंभिक प्रश्न यह है: "क्या यह हमेशा के लिए विवरणों को हटाने के बारे में है, उन्हें अस्थायी रूप से भूल गया है या यहां तक ​​कि किसी तरह से उनका उपयोग नहीं कर रहा है?

— 9

मुझे फर्क नहीं पड़ता कि आज मेरे ग्राहकों ने कितने फोटोन लिए हैं।

— राजहंस

Answer 22

मेरे लिए अमूर्तता एक ऐसी चीज है जो "सचमुच" मौजूद नहीं है, यह एक विचार की तरह कुछ है। यदि आप इसे गणितीय रूप से व्यक्त करते हैं, तो यह अब सार नहीं है क्योंकि गणित यह व्यक्त करने के लिए एक भाषा है कि आपके मस्तिष्क में क्या होता है इसलिए इसे किसी और के मस्तिष्क द्वारा समझा जा सकता है, इसलिए आप अपने विचारों को संरचना नहीं कर सकते, क्योंकि यदि आप करते हैं, तो यह एक विचार नहीं है। अब: आपको यह समझने की आवश्यकता होगी कि एक विचार मॉडल को व्यक्त करने के लिए मस्तिष्क कैसे काम करता है।

अमूर्तता एक ऐसी चीज है जो आपको वास्तविकता को किसी ऐसी चीज में व्याख्या करने की अनुमति देती है जो उससे स्वतंत्र हो सकती है। आप एक समुद्र तट और एक सपने को अमूर्त कर सकते हैं, लेकिन समुद्र तट मौजूद है लेकिन सपना नहीं है। लेकिन आप दोनों को बता सकते हैं, लेकिन यह सच नहीं है।

अमूर्तता में सबसे कठिन चीज इसे व्यक्त करने का एक तरीका मिल रहा है ताकि अन्य लोग इसे समझ सकें ताकि यह वास्तविकता में बदल सके। यह सबसे मुश्किल काम है, और यह वास्तव में अकेले नहीं किया जा सकता है: आपको एक रिश्तेदार मॉडल का आविष्कार करना होगा जो आपके विचारों पर काम करता है और जिसे किसी और द्वारा समझा जा सकता है।

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

इसे सीधे शब्दों में कहें, तो परमाणु एक दूसरे के बगल में हैं, लेकिन वे परवाह नहीं करते हैं। मनुष्य में संगठित अणुओं का एक बड़ा सेट यह समझ सकता है कि वह किसी के बगल में है, लेकिन यह समझ नहीं सकता है कि, यह कैसे परमाणुओं ने खुद को कुछ पैटर्न में बदल दिया।

एक वस्तु जो एक अवधारणा द्वारा शासित है, सामान्य रूप से, खुद को "समझ" नहीं सकती है। इसलिए हम भगवान पर विश्वास करने की कोशिश करते हैं और क्यों हमें अपने मस्तिष्क को समझने में कठिन समय लगता है।

क्या अब मैं अपना पदक हासिल कर सकता हूं?

Answer 23

दिलचस्प सवाल। मैं अमूर्तता की एक भी परिभाषा नहीं जानता, जिसे प्रोग्रामिंग के लिए आधिकारिक माना जाता है। हालांकि अन्य लोगों ने सीएस सिद्धांत या गणित की विभिन्न शाखाओं से कुछ परिभाषाओं के लिंक प्रदान किए हैं; मैं इसे "पर्यवेक्षण" के समान तरीके से देखना पसंद करता हूं, http://en.wikipedia.org/wiki/Servervience देखें

जब हम प्रोग्रामिंग में अमूर्तता के बारे में बात करते हैं, तो हम अनिवार्य रूप से एक प्रणाली के दो विवरणों की तुलना कर रहे हैं। आपका कोड एक प्रोग्राम का विवरण है। आपके कोड का अमूर्त होना भी उस कार्यक्रम का वर्णन होगा लेकिन "उच्च" स्तर पर। बेशक आप अपने मूल अमूर्त का एक भी उच्च स्तर अमूर्त हो सकता है (उदाहरण के लिए एक उच्च स्तरीय प्रणाली वास्तुकला में कार्यक्रम का विवरण बनाम इसकी विस्तृत डिजाइन में कार्यक्रम से विवरण)।

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

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

तो क्या वर्णन का एक स्तर दूसरे की तुलना में अधिक है? मान लीजिए कि हमारे पास विवरण ए का एक स्तर (जैसे डिज़ाइन दस्तावेज़) और विवरण बी का दूसरा स्तर (जैसे स्रोत कोड) है। A, B की तुलना में उच्च स्तर का है क्योंकि यदि A1 और A2, स्तर A पर दो गैर-समकक्ष विवरण हैं, तो उन विवरणों, B1 और B2 के अहसास भी स्तर B पर गैर-समतुल्य होने चाहिए । हालांकि, रिवर्स जरूरी नहीं है कि सही हो ।

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

Answer 24

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

ऑब्जेक्ट ओरिएंटेड डिज़ाइन पैटर्न एब्सट्रैक्शन का एक अच्छा उदाहरण है, और मुझे वास्तविक कार्यान्वयन का मतलब नहीं है लेकिन जिस तरह से हमें एक समाधान का दृष्टिकोण करना चाहिए।

तो, संक्षेप में, प्रोग्रामिंग अमूर्त एक दृष्टिकोण है जो हमें एक समस्या को समझने की अनुमति देता है, यह कुछ पाने का साधन है लेकिन यह वास्तविक चीज नहीं है