मैं किसी को ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग कैसे समझा सकता हूं जो केवल फोरट्रान 77 में कोडित है?

Question

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

क्या कोई सरल तरीका है जो मैं उन्हें समझा सकता हूं जो उसे समझने में मदद करेगा?

Comments

आप बढ़ई बने बिना पक्षी घर बना सकते हैं। हो सकता है कि वह उसे / प्रक्रियात्मक तरीके से करने वाले प्रोजेक्ट पर शुरू कर सकती है और आप उसे ओओपी तरीके से कैसे रिफैक्ट कर सकते हैं। कभी-कभी यह "मुझे

— ओओपी

क्या उसे वास्तव में ऑब्जेक्ट-ओरिएंटेड प्रोग्राम करने की आवश्यकता है, या क्या यह OpenFOAM का उपयोग क्रमबद्ध-प्रक्रियात्मक तरीके से करने के लिए पर्याप्त है?

— starblue

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

— एरिक पौली

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

— एंड्रियासचिनर्ट

Answer 1

संक्षिप्त उत्तर: नहीं।

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

OOP चर और कोड के टुकड़े को व्यवस्थित करने का एक तरीका है। OOP को परिभाषित करने के लिए कितने पैटर्न हैं? 25? 30? यहां तक ​​कि विभिन्न भाषाओं और पृष्ठभूमि से ओओपी सीखने वाले शिक्षक अपनी परिभाषा पर सहमत नहीं होते हैं, इसलिए ... यह कैसे सरल हो सकता है?

मुझे नहीं पता कि आप उस पर कैसे आए, लेकिन चूंकि आपकी मां को मेरा अनुभव समान है, इसलिए मैं आपको बता सकता हूं कि मैं कैसे आया।

मैं एक बहुत बड़े प्रोजेक्ट में C में प्रोग्रामिंग कर रहा था। यह 1988 था। कई प्रोग्रामर मॉड्यूल और लाइब्रेरी का आयोजन करते हैं, अन्य नौकरियों में हस्तक्षेप से बचने और कर्तव्यों का एक अच्छा पृथक्करण रखने की कठिनाई के साथ।

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

1996 में यह पता लगाना बहुत आसान था कि उन संरचनाओं को "कक्षाएं" नाम दिया गया था और उन फ़ंक्शन पॉइंटर्स को सदस्य फ़ंक्शन और वर्चुअल फ़ंक्शंस द्वारा प्रतिस्थापित किया गया था, या अन्य प्रोग्रामर द्वारा अन्य ऑब्जेक्ट्स (लिंक किए गए व्यवहार) के लिंक के साथ जिन्होंने उस पुराने प्रोजेक्ट को नवीनीकृत किया।

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

आज मैं OOP के साथ काम करता हूं, लेकिन मैं इसे सेवा करने के सिद्धांत के रूप में नहीं समझता: बस एक "सामान्य मुहावरा" (... का सेट) जो हमें हर समय लंबे स्पष्टीकरण और विवरण प्रदान करने की आवश्यकता के बिना एक साथ बोलते हैं। । वास्तव में, कुछ और की तुलना में अधिक "सम्मेलन"। सब के बाद, सभी OOP करता है -again- "यदि फिर गोटो": यह सिर्फ यह "बहुपरत" करता है। इसलिए मुहावरों पर अमूर्त और मुहावरे।

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

शीर्ष पर सिर्फ चार चीजें हैं, तो कोई भी "डेस्क को व्यवस्थित करने" के लिए नहीं सोचेगा। यह समझ में आता है जब शीर्ष पर मौजूद चीजें एक-दूसरे को बाधित करने लगती हैं। OOP के आने का समय है।

आपको C ++ के साथ काम करने के लिए OOP की आवश्यकता नहीं है। संपूर्ण C ++ मानक पुस्तकालय OOP के संदर्भ में डिज़ाइन नहीं किया गया है (हालांकि यह इसके साथ सहयोग कर सकता है), और C ++ जावा नहीं है।

मेरे सभी अनुभव में सबसे खराब C ++ शिक्षक और C ++ प्रोग्रामर हैं जो जावा से आते हैं, अपने सभी पूर्वाग्रहों के बारे में सब कुछ OOP नहीं सिखा रहे हैं, C ++ जैसी भाषा को निरूपित कर रहे हैं जो OOP के लिए (सिर्फ) नहीं है।

मुझे उन लोगों के लिए एक अच्छी पुस्तक का सुझाव दें जो C ++: त्वरित C ​​++ को अप्रोच करना चाहते हैं : यह आपको पूर्वनिर्धारित सिद्धांत का पालन करने का बहाना किए बिना C ++ मुहावरों में लाएगा।

Comments

उसे OpenFOAM के साथ काम करने के लिए c ++ जानने की आवश्यकता है, इसलिए उसे निश्चित रूप से जल्द ही कक्षाएं जानने की आवश्यकता होगी। मुझे लगता है कि वह इसके पीछे के मूल विचारों को समझती है। हालांकि किसी कारण से, वह 'डॉट स्ट्रक्चर' पर फंसती हुई दिख रही है। (यानी System.out.println (), c ++ को छोड़कर)

— Eric Pauley

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

— SK- तर्क

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

— हर्बी

Answer 2

एक पुराने मित्र ने दावा किया कि मेरे पास ओओ प्रोग्रामिंग की सबसे छोटी परिभाषा थी, और मैंने पाया है कि यह कुछ लोगों के लिए काम करता है (और दूसरों के लिए नहीं):

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

विचार यह है कि व्यक्ति को इस बारे में अलग तरह से सोचने के लिए कि चीजों को उनके कार्यक्रम के अंदर कैसे लाया जाए।

Comments

+1 यह "पूछो, बताओ मत" से भी जाता है।

— user949300

आपका मतलब है "बताओ, मत पूछो"। :)

— रेमन लियोन

Answer 3

उसे वास्तविक दुनिया की वस्तुओं की तरह सोचने के लिए कहें। उदाहरण के लिए पूरी दुनिया ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का मिश्रण हो सकती है (C ++ में) कुछ प्रकार की कार्यात्मक प्रोग्रामिंग के साथ (शायद भगवान की भाषा में, लिस्प)।

एक वस्तु लें, उदाहरण के लिए लॉन घास काटने की मशीन, इसकी एक निश्चित विशेषता है, और यह एक निश्चित कार्य कर सकती है। (वस्तु और वर्ग)

फिर उसे एक बेहतर लॉन घास काटने की मशीन के बारे में बताएं जो आपके पास पहले से मौजूद लॉन घास काटने की मशीन का विस्तार है। उसे बेहतर बताएं लेकिन फिर भी उसी तंत्र (विरासत) पर निर्माण करता है।

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

जब तक वह इसे प्राप्त करती है, तब तक उसे बताएं कि उसे इन चीजों को किस भाषा में सीखना है (C ++)।

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

जब वह जानती है कि वास्तविक दुनिया के अपने विचारों को प्रोग्राम कोड में कैसे बदलना है। उसने सीखा होगा कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज में कैसे प्रोग्राम करना है।

Comments

@Zonedabone कोई समस्या नहीं है, मुझे OOP सीखने में 1 साल का समय लगा (मैंने अपने दम पर सीखा), लेकिन मैंने उन्हीं उदाहरणों का इस्तेमाल किया :) और अचानक प्रबुद्ध महसूस किया। LOL

— अनिकेत इंजी

नहीं नहीं नहीं नहीं नहीं! मेरे अनुभव में "वास्तविक दुनिया में वस्तुओं के बारे में सोचते हैं" किसी को OOP की व्याख्या करने का एक भयानक तरीका है जो पहले से ही इसे नहीं समझता है। यह विचित्र गलतफहमी और OOP की गलतफहमी की ओर जाता है, और अक्सर भ्रम को गहराता है।

— जेएसबी JS

बहुरूपता के लिए नियम अनुकूलन की तरह है। नियम A) यह मत करो। नियम B) (केवल विशेषज्ञों के लिए!): अभी तक ऐसा न करें।

— 2

JSB ձոգչ से सहमत हैं। यह OOP की व्याख्या करने का एक बहुत ही सामान्य तरीका है, लेकिन मेरी राय में यह वास्तव में अनपेक्षित है। प्रोग्रामिंग में वस्तुएं वास्तव में वास्तविक जीवन में वस्तुओं की तरह कुछ भी नहीं हैं।

— रोवन फ्रीमैन

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

— Pieter B

Answer 4

मैं असेंबलर और COBOL से रूबी में गया हूं।

शुरू में मुझे जो मदद मिली वह वास्तव में उदाहरणों को बनाने वाली कक्षाओं की अवधारणा की अनदेखी थी।

बस कोड के साथ शुरू करते हैं। एक कक्षा है, लेकिन सिर्फ कक्षा स्तर के तरीके हैं। तरीकों के भीतर बहुत सारा सामान मापदंडों, चर, सशर्त, सरणियों, तार, बूलियन आदि के बारे में है। यह सामान परिचित होना चाहिए।

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

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

यह एक शुरुआत है।

ठीक है अब इस तथ्य पर विचार करें कि आप कई कैलकुलेटर खोलना चाहते हैं और बदलते हैं कि प्रत्येक स्क्रीन पर कैसा दिखता है और यह कहां है। इसलिए अब आपके पास 'screen_location' जैसी कैलकुलेटर विधि नहीं हो सकती है क्योंकि आपके पास उनमें से कई हैं और प्रत्येक उदाहरण का अपना स्थान है ... प्रत्येक उदाहरण ... ठीक है, इसलिए हमें उदाहरणों की आवश्यकता है।

नोट: मेरी शर्तें रूबी नहीं हैं c ++ से इसलिए आपको अनुवाद करने की आवश्यकता हो सकती है।

Answer 5

मैं इसे दो चरणों में समझाऊंगा, या शायद चार को, इस बात पर निर्भर करता है कि आप अपनी अवधारणाओं को विभाजित करना कितना पसंद करते हैं।

चरण 1: संरचनाओं के लिए उसका परिचय दें। यह फोरट्रान डेटा प्रकारों से संरचनाओं के लिए काफी छोटा कदम है। चरण 1 ए: सुनिश्चित करें कि वह कमज़ोर गतिशील मेमोरी आवंटन और संकेत देता है।

चरण 2: केवल उन संरचनाओं से जुड़ी प्रक्रियाएं जोड़ें। चरण 2 ए: बड़ी संरचनाओं के निर्माण के आधार पर वंशानुक्रम जोड़ें जो छोटी संरचनाओं को "लपेट "ते हैं।

एक फोरट्रान प्रोग्रामर के लिए, "वाह" कारक यह होगा कि यह कंपाइलर का ट्रैक रखने के लिए बहुत कुछ है। हाँ। यही कारण है कि संकलक के लिए कर रहे हैं ...

Comments

मुझे लगता है कि वह वस्तुओं के पीछे की प्रक्रिया को समझती है। यह सिर्फ इसलिए कि किसी कारण से वह डॉट्स को नहीं समझती है। ('।') यह वास्तव में अजीब है। मुझे लगता है कि जब आप कोडिंग शुरू करते हैं जब सब कुछ मैन्युअल रूप से (आवंटन और सामान) करना होता है तो आप जानते हैं कि आधुनिक भाषाओं के आंतरिक कामकाज कैसे काम करने के लिए जाने बिना काम करते हैं।

— एरिक पौली

Answer 6

यदि उसने एक दशक पहले अपनी थीसिस की थी, तो उसने शायद फोर्टन 90 या 95 का उपयोग किया, जिस मामले में व्युत्पन्न डेटा प्रकारों के संबंध में बात की जाती है। यदि यह काफी पहले था कि वह फोरट्रान 77 का उपयोग करती है, तो उसे फ़ोर्ट्रान 90 में व्युत्पन्न डेटा प्रकारों से परिचित कराएं और फिर इसके बारे में बात करें ...

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

Answer 7

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

नॉन-ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में, यदि कोई ट्री और लिंक्डलिस्ट के लिए अलग-अलग डेटा प्रकारों का उपयोग कर रहा है, तो प्रत्येक को नोड जोड़ने के लिए अलग-अलग तरीकों का उपयोग करना होगा। गैर-वस्तु उन्मुख भाषाओं आम तौर पर पक्षी का कर्कश शब्द अगर एक दोनों तरीकों नाम करने की कोशिश की हैं AddItem, के बाद से किसी भी नाम केवल एक ही विधि का उल्लेख कर सकते हैं, इस प्रकार की तरह विधि के नाम बनाने के लिए एक अग्रणी AddTreeItem, AddLinkedListItem, RemoveTreeItem, आदि इस तरह के एक दृष्टिकोण काम करता है, लेकिन यह एक सा बदसूरत। वैचारिक रूप से, तरीके AddTreeItemऔर RemoveTreeItemएक साथ लगते हैं, लेकिन नाम उस तरह से सॉर्ट नहीं करते हैं। एक नाम के रूप में फिर से लिखने सकता है TreeAddItem, TreeRemoveItem,LinkedListAddItem, आदि लेकिन यह कि प्रत्येक विधि आह्वान की शुरुआत में बहुत "अनावश्यक शोर" होगा। एक विशिष्ट कार्यक्रम में विधि कॉल के विशाल बहुमत में तीन आवश्यक जानकारी होगी: (1) स्रोत कोड के किस भाग में विधि शामिल है; (2) अनुभाग में किन विधियों का उपयोग किया जा रहा है; (३) डेटा के किस टुकड़े पर कार्रवाई की जा रही है? कई मामलों में, जिस प्रकार के डेटा पर कार्रवाई की जा रही है, वह यह पहचानने के लिए पर्याप्त होगा कि विधि किस कोड अनुभाग से संबंधित है, इसलिए उपरोक्त भाग (1) निरर्थक है। कहीं और सामग्री की तुलना में एक बयान की शुरुआत में सामग्री की पहचान करना आसान है, इसलिए एक कोडिंग / नामकरण शैली जैसे TreeAddItem(myTree, whatever)कि मुख्य स्थान पर कम से कम उपयोगी जानकारी डालते हैं।

इसके विपरीत, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग करते हुए, कोई प्रभावी तरीके के रूप में नाम देगा Tree.AddItem, इत्यादि और एक बयान जैसे myTree.AddItem(whatever)कि एक संकलक का कारण होगा, अनिवार्य रूप से, "हम्म ... myTreeप्रकार का है Tree, इसलिए इस कोड को लागू करना चाहिए Tree.AddItem()। यह आवश्यक नहीं है। कंपाइलर के प्रकार को जानने के बाद से Tree.कॉल करते समय निर्दिष्ट करें । वैचारिक रूप से, जैसे कथन के बराबर है , और कुछ ऑब्जेक्ट-ओरिएंटेड भाषाएं दोनों रूपों को समान रूप से अनुमति दे सकती हैं; वास्तव में, अधिकांश भाषाएँ फ़ंक्शन विनिर्देश से पहले पैरामीटर को छोड़ देती हैं और इसके बजाय होती हैं; विधियाँ जो एक वर्ग में परिभाषित की जाती हैं, जैसे कि एक प्रकार का पैरामीटर , और इसे एक नाम निर्दिष्ट करें , जैसे , या ।AddItemmyTreemyTree.AddItem(whatever)Tree.AddItem(myTree, whatever)TreeTreethisselfMe

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

Answer 8

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग-यहाँ क्लास-ओरिएंटेड सेंस में प्रासंगिक है - कोड के साथ डेटा प्रतिनिधित्व को युग्मित करने के बारे में है जो इसे हेरफेर करता है। यह समझ में आता है अगर निम्नलिखित बातें समझ में आती हैं:

• युग्मन: उस डेटा प्रतिनिधित्व के साथ एक ऑपरेशन को परिभाषित करना जिस पर वह काम करता है

• देर से बाध्यकारी: रनटाइम पर डेटा प्रतिनिधित्व और व्यवहार का एक संयोजन चुनना

• एनकैप्सुलेशन: यह सुनिश्चित करना कि डेटा निर्माण द्वारा मान्य है और बाद में अमान्य नहीं होगा

बस इतना ही। किसी भी तकनीक की तरह , इसके दिल में यह एक सुविधा है, जिसमें से बाद में कई विकास हुए हैं। एक बार जब आप मूल बातें समझ लेते हैं, तो बाकी समय में समाप्त हो जाती है।

Answer 9

मेरा सुझाव है कि ब्लूज को डाउनलोड करना, 20 मिनट तक उसके साथ खेलना और फिर 20 मिनट तक उसके साथ खेलना।

जिस तरह से यह कक्षाओं, इंटरफेस और विरासत की कल्पना करता है वह इतना स्पष्ट और सहज है कि यह वास्तव में आपको तुरंत समझ देता है क्योंकि आप कुछ - कुछ भी लागू करते हैं।

यहां तक ​​कि यह आपको एक वर्ग और वस्तु के बीच का अंतर भी दिखाता है

यह OO डिजाइन पैटर्न में कोई गहरी अंतर्दृष्टि नहीं देगा, लेकिन यह अवधारणाओं का एक शानदार अवलोकन देगा।

Answer 10

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

इसलिए, मेरी राय में, F ++ उपयोगकर्ता के लिए C ++ के साथ ऑब्जेक्ट ओरिएंटेशन की व्याख्या करने का सबसे अच्छा तरीका, चरणबद्ध तरीके से आगे बढ़ना होगा:

सबसे पहले, उपयोगकर्ता को एक परिचित सेटिंग में ऑब्जेक्ट ओरिएंटेशन की अवधारणा से परिचित कराएं, जिससे उसे पता चलता है कि फोरट्रान 77 में ऑब्जेक्ट-जैसी संरचनाओं को कैसे विकसित किया जाए - उदाहरण के लिए, बी पैटन जैसे कागजात पर एक नज़र डालें "ऑब्जेक्ट-ओरिएंटेड फोरट्रान 77 (एक चिकित्सक) देखें) "सिग्लान फोरट्रान फोरम 12, 2 (1993), पीपी। 23-24, और उसमें संदर्भ।

फिर, उन संरचनाओं और C ++ कक्षाओं और विधियों के बीच एक पत्राचार स्थापित करें।

अंत में, अतिरिक्त सुविधाओं पर चर्चा करें जो C ++ OO प्रोग्रामिंग की सुविधा प्रदान कर सकती हैं।

Answer 11

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

यह वास्तव में एक चर के लिए वास्तव में किसी अन्य चर से संबंधित है, खासकर जब आप उन्हें संकेत के रूप में सोचने के लिए उपयोग किया जाता है। मेरे लिए ठोकर थी:

• किसी चीज़ के लिए इसका क्या मतलब है जो मूल रूप से एक पॉइंटर है, एक अन्य पॉइंटर को इंगित करने के लिए, जो कि पेरेंट पॉइंटर की तुलना में एक अलग चीज़ का समाधान करता है?

मेरे लिए अहा पल था जब मुझे एहसास हुआ कि शीर्ष स्तर का सूचक मूल रूप से सिर्फ एक नामस्थान था।

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

उस व्यायाम को करते हुए उसे प्रारंभिक "क्या जादू टोना है?" बाधा।

Answer 12

एक प्रमुख अंतर्दृष्टि जिसने मुझे समझाने में पहले मदद की है वह यह है कि आपके पास एक वर्ग के कई उदाहरण हो सकते हैं। यह समझाने की कोशिश करें कि "आरेखण" या "नए नए साँचे" और "कॉपियाँ" के संदर्भ में और देखें कि क्या यह कहीं जाता है।

Comments

वास्तव में downvotes समझ नहीं है। समझाने के इस तरीके ने मुझे कई बार मदद की है। यह नहीं कह रहा है कि यह एक चांदी की गोली है, लेकिन ऐसा लगता है कि लोग इस पर अटक जाते हैं।

— अलेक्जेंडर टॉर्टलिंग