भौतिक वास्तविक दुनिया की वस्तुओं को संदर्भित किए बिना कोई ओओ को कैसे सिखा सकता है? [बन्द है]

Question

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

Comments

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

— टॉम एंडरसन

शिक्षण के दौरान आप परिचित, समझने योग्य, वास्तविक दुनिया की वस्तुओं से क्यों बचना चाहेंगे?

— एडम क्रॉसलैंड

हालांकि यह एक दिलचस्प सवाल है। OO को भौतिक में निहित किया गया है या नहीं, और भौतिक दुनिया के संदर्भ में OO को पढ़ाना एक अच्छा विचार है या नहीं, यह भौतिक दुनिया के संदर्भ के बिना इसे सिखाने के लिए एक उत्पादक तरीके को जानना बेहतर होगा।

— टॉम एंडरसन

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

— होरस्कॉल

@ हॉर्सकॉल: आपके पास बिल्कुल पीछे की तरफ है। अंतर्निहित डोमेन मॉडल भोजन है। यह लगभग हमेशा वास्तविक दुनिया की वस्तुओं पर केंद्रित है। नहीं तो सॉफ्टवेयर क्यों लिखें? GUI या वेब प्रस्तुति केवल सेवारत प्लेट है। दिलचस्प है, प्रस्तुति इतनी कोशिश करती है। शायद यह उपकरण की प्रधानता के बारे में कुछ कहता है।

— एस.लॉट

Answer 1

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

EDIT: आज का OO पूरी तरह से स्व-निहित ऑब्जेक्ट बनाने के बारे में है, जिनके गुणों और क्षमताओं को विभिन्न विधियों (फ़ंक्शन) और विशेषताओं (संदर्भ AKA चर और स्थिरांक) का उपयोग करके पूरी तरह से / आंशिक रूप से वर्णित किया गया है।

Answer 2

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

यह "ऑब्जेक्ट विस्फोट", अति-सामान्यीकरण, और गलत रूपक विकल्प को भी रोकता है जो सभी सामान्य गलतियाँ हैं।

Comments

+1 वास्तव में सादृश्य के उत्तर देने के बजाय प्रश्न का उत्तर देने के लिए आवश्यक है!

— स्टीवन ज्यूरिस

मुझे यह भी लगता है कि यह ओओ का बहुत सार है। यह OO को एक तरह से समझाता है कि इसके फायदे क्या हैं, इसके बजाय यह कैसा दिखता है। सूची में पुन: स्थान जोड़ें, और मैं इस उत्तर को फिर से बनाना चाहूंगा। ; पी

— स्टीवन ज्यूरिस

Answer 3

मैं वास्तविक दुनिया की वस्तुओं पर ध्यान केंद्रित नहीं करूंगा, और मैं मैसेजिंग पर भी ध्यान केंद्रित नहीं करूंगा। बल्कि एक उदाहरण जो मैंने प्रयोग किया है वह ग्राफिक्स में है, जहाँ आप ऐसी वस्तुओं को रखना चाहते हैं जो "खुद को आकर्षित करना जानते हों"।

यदि आप C में काम कर रहे हैं, उदाहरण के लिए, जिसमें OO निर्मित नहीं है, तो आपको पॉइंटर्स को डेटा ऑब्जेक्ट्स के अंदर फ़ंक्शन के लिए स्टोर करना सुविधाजनक लग सकता है। यदि आप करते हैं, तो आप OOP में अपना रास्ता बदल रहे हैं।

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

Comments

यदि आप चर्चा के माध्यम से पढ़ते हैं तो मैंने संदर्भित किया है कि आप देखेंगे कि यह बताया गया है कि एलन केओ को ओओ के रूप में संदर्भित किया गया है, जिसका आधुनिक ओओ से कोई लेना-देना नहीं है ... इसलिए मैंने इसे संदर्भित किया है।

— केनेथ

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

— माइक डनलैवी

@ मायक शायद आप अभी भी गलत समझ रहे हैं कि मैं क्या कह रहा हूं ... मैंने उस चर्चा का संदर्भ दिया जो मैंने किया था कि उनके मूल विचार क्या थे आज के ऊ पर ज्यादा लागू नहीं होते हैं। मैं निश्चित रूप से उनके विचारों की पूजा नहीं करता या उनका अध्ययन भी नहीं करता।

— केनेथ

@ केनेथ: मैं अपने "हॉट-बटन" में लिपटा हुआ हूं, जैसे कि मैंने सुना है कि लोग सच्चे ओओपी के बारे में बात करते हैं , या एके का वास्तव में क्या मतलब है। माफ़ करना।

— माइक डनलैवी

@ मायके एलन के का कहना है कि वह माइक्रोबायोलॉजी में अपने प्रशिक्षण से बहुत प्रेरणा लेते हैं। विशेष रूप से, एक वस्तु की उसकी अवधारणा थी (और मुझे याद नहीं है कि सेल के आधार पर उसके कौन से कागजात / वार्ता में उसका उल्लेख है)।

— फ्रैंक शीयर

Answer 4

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

इसलिए बिना भौतिक उदाहरणों का उपयोग किए इसे सिखाने के लिए मैं किसी भी उदाहरण का उपयोग नहीं करने का सुझाव दूंगा, लेकिन मैं यह नहीं देखता कि आप भौतिक उदाहरण क्यों नहीं चाहते हैं, इसलिए इस विषय पर मेरा रुख है

नहीं, आपको इसे भौतिक वास्तविक दुनिया की वस्तुओं के बिना नहीं सिखाना चाहिए

Answer 5

मुझे नहीं कैसे आप बच सकते हैं शुरू कर वास्तविक दुनिया रूपकों में बाहर है, लेकिन आप नहीं चाहते कि रहने वहाँ। यदि आप OOP सही कर रहे हैं, तो यह जल्दी से अमूर्त हो जाता है, लेकिन समझ के अगले स्तर पर, शिक्षार्थी को वस्तुओं को समझना चाहिए।

Answer 6

दिलचस्प बात यह है कि मेरे कुछ पसंदीदा उदाहरण भौतिक वस्तुएं नहीं हैं। उदाहरण के लिए बैंक खाता लें। सभी को "क्यों" जमा () और निकासी () सेवा शुल्क लेना चाहिए, बजाय कॉलिंग कोड पर भरोसा करने के और संतुलन के मूल्य को बदलने के लिए और सेवा शुल्क को हटाने के लिए याद रखना चाहिए। एक स्क्रीन पर आकार दोगुने अमूर्त हैं, और स्ट्रॉस्ट्रुप ने मुझे बताया कि क्लासिक "आकृतियाँ" उदाहरण दो सबसे पुराने ओओ उदाहरणों में से एक है जिसे वह जानते हैं, 40 साल पहले डेटिंग (अब वाहन 44 साल का है।)

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

Answer 7

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

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

Comments

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

— कॉर्मैक मुलहाल

Answer 8

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

यह स्पष्टीकरण पारंपरिक गणित / कंप्यूटर विज्ञान के कार्यान्वयन के तरीके को स्वतंत्र रूप से अवधारणा को पढ़ाने का विरोधाभास देता है, लेकिन यह वह परिप्रेक्ष्य है जिसने मुझे बनाया है (बेशक एक इंजीनियरिंग, एक COMP विज्ञान, पृष्ठभूमि के साथ किसी को नहीं) आखिरकार ओओ मिलता है।