OOP क्यों मुश्किल है? [बन्द है]

Question

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

OOP को समझना मुश्किल क्यों है? क्या यह समझना मुश्किल है?

Comments

मैं इसके साथ मुकाबला करता हूं: यह समझना मुश्किल नहीं है, बस मास्टर करना मुश्किल है। समग्र रूप से प्रोग्रामिंग इस तरह से है।

— स्टीवन एवर्स

उम, यह नहीं है? शायद प्रोग्रामर जो खिचड़ी भाषा का कार्यक्रम कोड की अपनी लाइनों के बजाय ऊप्स को दोष देना मुश्किल है? मैं नहीं जानता, लेकिन मैंने कभी नहीं सुना कि किसी को भी समझने में मुश्किल हो। हालाँकि, मैंने देखा कि ppl का कहना है कि कार्यात्मक अजीब है क्योंकि वे अपने चर के मूल्य को बदल नहीं सकते।

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

— कोमोनॉड

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

— मिंगकोड्स

क्योंकि यह गलत है। यह वास्तव में Subject ओरिएंटेड प्रोग्रामिंग होनी चाहिए, जिसमें Subject एक्शन (क्रिया) करता है और ऑब्जेक्ट एक्शन प्राप्त करता है - जॉन ने गेंद फेंकी। तो johnsBall.throw () वास्तव में मतलब नहीं है।

— क्रिस कूडमोर

Answer 1

मैंने व्यक्तिगत रूप से OOP के यांत्रिकी को आसानी से समझ लिया। मेरे लिए कठिन हिस्सा "क्यों" का था। जब मैं पहली बार सामने आया था, तो यह एक समस्या की तलाश में एक समाधान की तरह लग रहा था। यहाँ कुछ कारण हैं जो मुझे लगता है कि ज्यादातर लोगों को यह मुश्किल लगता है:

1. शुरुआत से ही OO को सिखाना एक भयानक विचार है। प्रक्रियात्मक कोडिंग एक "बुरी आदत" नहीं है और कुछ नौकरियों के लिए सही उपकरण है। किसी OO प्रोग्राम में अलग-अलग तरीके किसी भी तरह से सुंदर प्रक्रियात्मक होते हैं। इसके अलावा, प्रक्रियात्मक प्रोग्रामिंग सीखने के लिए अपनी सीमाओं को अच्छी तरह से देखने के लिए पर्याप्त होने से पहले, OO छात्र के लिए बहुत उपयोगी नहीं लगता है।

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

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

Comments

शानदार उत्तर, विशेष रूप से संख्या # 1। बेशक ओओ में विधियां एक प्रक्रियात्मक अंतराल में तरीकों की तरह दिखती हैं, लेकिन अब वे उन वस्तुओं में रखे जाते हैं जिनमें राज्य भी होते हैं।

— डैन रोसेनस्टार्क

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

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

+1 के लिए "मेरे लिए कठिन हिस्सा" इसका "क्यों" था। भाषा के मूल (एनकैप्सुलेशन) और डिजाइन सिद्धांतों और रीफैक्टरिंग विधियों को सामान्य समाधानों (डिजाइन पैटर्न) को समझने और लागू करने में कुछ समय और प्रयास लगता है।

— बेलुन

मैं # 1 के साथ सहमत हूं, इस चेतावनी के साथ कि आपको उन लोगों को OO समझाने का एक बेहतर काम करने की आवश्यकता है जो पहले से ही जानते हैं कि जब मैं सीख रहा था तो प्रक्रियात्मक रूप से कैसे प्रोग्राम किया जाए। नहीं, यह उस Catवर्ग के बारे में बात करने के लिए उपयोगी या सूचनात्मक नहीं है जो विरासत में मिला है Mammal, एक वास्तविक कार्यक्रम से एक वास्तविक उदाहरण का उपयोग करें जिसे हमने प्रक्रियात्मक रूप से लिखा होगा। एक साधारण डेटा संरचना की तरह।

— कार्सन 63000 22

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

— सिजेरोन

Answer 2

मुझे लगता है कि कुछ ऐसे कारक हैं जिनका उल्लेख अभी तक नहीं किया गया है।

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

दूसरा, OOP में विरासत ज्यादातर लोगों के मानसिक मॉडल का बहुत बारीकी से पालन नहीं करता है। अधिकांश लोगों के लिए, चीजों को वर्गीकृत करना विशेष रूप से कहीं भी नहीं है जो वर्ग पदानुक्रम बनाने के लिए आवश्यक पूर्ण नियमों के करीब हो। विशेष रूप से, जो class Dकि दूसरे से विरासत में मिला है बनाने का class Bमतलब है कि सभी विशेषताओं को class Dसकारात्मक रूप से साझा करना । अपनी खुद की नई और अलग विशेषताओं को जोड़ सकते हैं, लेकिन सभी विशेषताओं को बरकरार रहना चाहिए।class Bclass Dclass B

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

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

1. एक कार के पास कितने पहिए हैं, इस बारे में कुछ भी न कहें - लेकिन इससे यह अनुमान लगाया जाता है कि यह हमेशा 4 होगा, और कोड जो किसी अन्य संख्या के लिए टूटने की संभावना है।
2. दावा करें कि सभी कारों में चार पहिये होते हैं, और बस उन अन्य लोगों को "कार नहीं" के रूप में वर्गीकृत करते हैं, भले ही हम जानते हैं कि वे वास्तव में हैं।
3. पहियों की संख्या में भिन्नता की अनुमति देने के लिए कक्षा को डिज़ाइन करें, बस मामले में, भले ही यह एक अच्छा मौका है कि इस क्षमता की कभी आवश्यकता नहीं होगी, इसका उपयोग किया जाएगा, या ठीक से परीक्षण किया जाएगा।

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

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

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

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

Comments

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

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

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

— rmac

टेबल ओरिएंटेड प्रोग्रामिंग की तरह लगता है , हालांकि मैं कहूंगा कि मुझे यह महसूस करना है कि OOP सॉफ्टवेयर डेवलपमेंट की सिल्वर बुलेट नहीं है।

— ओनेसिमस यूएनबाउंड

@OnesimusUnbound: अंतर यह है कि जेनेरिक प्रोग्रामिंग कुछ करने का एक वास्तविक, व्यावहारिक तरीका है, जबकि टेबल ओरिएंटेड प्रोग्रामिंग ज्यादातर एक सिद्धांत के बारे में एक पागल है कि कैसे कुछ काम कर सकता है (इस बारे में TopMind के पुराने पोस्ट के माध्यम से पढ़ सकते हैं। 'मैं देखूंगा कि मेरा क्या मतलब है - वास्तव में, पद सभी पुराने नहीं हो सकते हैं; सभी के लिए मैं जानता हूं, वह आज भी जारी है)।

— जेरी कॉफिन

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

— इवान प्लाइस

Answer 3

ओओपी को सार रूप से सोचने की क्षमता की आवश्यकता होती है; एक उपहार / अभिशाप है कि कुछ लोग, यहां तक ​​कि पेशेवर प्रोग्रामर, वास्तव में हैं।

Comments

सभी प्रोग्रामिंग सार है।

— जेएफओ

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

— जॉन क्राफ्ट

किसी को 2 पेंसिल सौंपना और फिर उन्हें 1 पेंसिल सौंपना और यह पूछना कि उनके पास कितनी पेंसिल हैं, ठोस है। 2 + 1 = 3 सार है।

— जेफओ

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

— कोनराड रुडोल्फ

@KonradRudolph ग्रेट पॉइंट। +1 के लिए "सब कुछ अमूर्त के बिना बहुत जटिल होगा" ।

— कार्तिक श्रीनिवासन २४'२२:

Answer 4

मुझे लगता है कि आप इस तरह से मूल कठिनाई को संक्षेप में बता सकते हैं:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

ज़रूर, लोग 270 के रूप में "बाएं" की मैपिंग के लिए उपयोग कर सकते हैं, और हाँ, "कार को चालू करें" के बजाय "कार को चालू करें" इतनी बड़ी छलांग नहीं है। लेकिन, इन वस्तुओं के साथ अच्छी तरह से निपटने के लिए और उन्हें बनाने के लिए, आपको उस तरह से पलटना होगा जैसा आप सामान्य रूप से सोचते हैं।

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

Comments

अच्छी अंतर्दृष्टि। मुझे लगता है कि समस्या यह है कि वास्तविक जीवन में, इतनी "ऑब्जेक्ट" नहीं है जो अन्य वस्तुओं से संबंधित नहीं है। OO अब तक अच्छी तरह से काम करता है जहाँ वस्तुओं को अपनी आंतरिक स्थिति को संशोधित करने के लिए कहा जाता है: rectangle.enlarge (मार्जिन_in_pixels) लेकिन मुझे वर्षों पहले सीमा का एहसास हुआ। एक दिन हम प्रोग्रामर हार्डवेयर इंस्टॉल कर रहे थे। किसी ने समझदारी से "स्क्रू। टर्न" का मजाक उड़ाया, लेकिन यह मुझे सोच में पड़ गया: यकीन है, एक स्क्रू इसे ओरिएंटेशन बदल सकता है, लेकिन यह वास्तव में कैबिनेट और स्क्रू के बीच एक ऑपरेशन है; न तो वस्तु ही कार्य कर सकती है। OO बस अच्छा नहीं है

— डेरेनडब्ल्यू

+1, "रूट (दिनांक, 0,4)" लिखने के वर्षों के बाद, "दिनांक.substring (0,4)" लिखना कठिन है

— ern0

कोड स्निपेट के लिए +1। इसमें स्पष्ट रूप से एक वास्तविक विचार प्रक्रिया को दर्शाया गया है।

— कार्तिक श्रीनिवासन

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

— बंगलेस्टिंक

अच्छा इंजी, इसलिए ओबीओपी "एजेंटों की प्रणाली" मॉडलिंग के लिए अधिक उपयुक्त है?

— Qbik

Answer 5

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

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

• महत्वपूर्ण नाम विषम नामों के पीछे छिपे हुए हैं (FP: What is a monad? OOP: वे उन्हें कभी-कभी फ़ंक्शन क्यों कहते हैं और अन्य समय के तरीके?)

• विषम अवधारणाओं को रूपक में समझाया जाता है बजाय इसके कि वे वास्तव में क्या करते हैं, या आप उनका उपयोग क्यों करेंगे, या किसी ने कभी उनका उपयोग करने के लिए क्यों सोचा (FP: A monad is a spaceuit), यह कुछ कोड को लपेटता है। OOP: An ऑब्जेक्ट एक बतख की तरह है, यह शोर कर सकता है, चलना और पशु से विरासत में मिल सकता है)

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

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

छोटी छलांग बाद में समझ को परिष्कृत करने में मदद करती है, लेकिन यह शुरुआती है जो किसी व्यक्ति को "ओओपी से कोई मतलब नहीं है, लोग ऐसा क्यों करते हैं?" "OOP सबसे अच्छा है, लोग कुछ और क्यों करते हैं?"

Comments

मुझे विशेष रूप से रूपक से नफरत है, अधिक बार नहीं, वे वर्णन करने के बजाय भ्रमित करते हैं।

— रयान

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

— जारेड अपडेटाइक

अवधारणाओं की व्याख्या करने के लिए रूपकों का उपयोग करने के साथ मेरी समस्या यह है कि शिक्षक अक्सर रूपक पर रुक जाता है, जैसे कि वह पूरी बात समझाता है। ऐसा नहीं है कि एक पूर्ण विवरण नहीं है; यह वास्तविक व्याख्या के चारों ओर हमारे सिर को लपेटने में मदद करने के लिए सिर्फ एक उदाहरण है ।

— झनक

बहुत बढ़िया जवाब! +1 यह समझाने के लिए कि ओओपी को समझने के लिए पहला कदम, नींव की अच्छी समझ के साथ प्राकृतिक एक्सटेंशन के रूप में बाद में आने से अधिक महत्वपूर्ण होगा। : D

— कार्तिक श्रीनिवासन

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

— राडारोब

Answer 6

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

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

Answer 7

मैं अधिकांश भाग के लिए dsimcha के उत्तर से असहमत हूं:

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

2. अच्छे OO कार्यक्रमों में अलग-अलग तरीके सभी को देखते हुए प्रक्रियात्मक नहीं होते हैं। यह OO भाषाओं के विकास के साथ अधिक से अधिक सच होता जा रहा है (C # पढ़िए क्योंकि C ++ से इतर यह केवल अन्य OO भाषा है जो मुझे पता है) और उनका सिंटैक्स जो दिन (लैम्ब्डा, LINQ से ऑब्जेक्ट्स इत्यादि) तक अधिक जटिल हो रहा है। ओओ के तरीकों और प्रक्रियात्मक भाषाओं में प्रक्रियाओं के बीच एकमात्र समानता प्रत्येक की रैखिक प्रकृति है, जो मुझे संदेह है कि जल्द ही कभी भी बदल जाएगा।

3. आप डेटा संरचनाओं को समझने के बिना एक प्रक्रियात्मक भाषा में महारत हासिल नहीं कर सकते। सूचक अवधारणा प्रक्रियात्मक भाषाओं के लिए उतनी ही महत्वपूर्ण है जितनी कि OO भाषाएँ। उदाहरण के लिए, संदर्भ से पैरामीटर पारित करना, जो प्रक्रियात्मक भाषाओं में काफी सामान्य है, आपको पॉइंटर्स को समझने की आवश्यकता है जितना कि किसी भी ओओ भाषा को सीखने के लिए आवश्यक है।

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

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

Comments

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

— गैरी विलोबी

+1 - शानदार जवाब। मुझे आपके द्वारा बताई गई 4 वीं बात पसंद है। यह बहुत ही सही है कि कोई भी अच्छा ओओ प्रोग्रामर हो सकता है, बिना यह जाने कि डिजाइन पाट्र्स वास्तव में क्या हैं!

— कार्तिक श्रीनिवासन

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

— इवान प्लाइस

Answer 8

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

Answer 9

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

Answer 10

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग अपने आप में कठिन नहीं है।

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

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

Comments

"मेरा व्यक्तिगत अनुभव यह है कि इस समय बहुत अच्छी तरह से करने के लिए आपको उन सभी स्थितियों में बहुत अभ्यास की आवश्यकता होती है, जहाँ आप यह चाहते हैं कि आपने इसे अलग तरह से किया है।" OOP यह गलत नहीं करने के तरीकों की एक कोडित सूची की तरह लगता है, जो तब तक समझ में नहीं आता जब तक कि आपने उन सभी तरीकों से गलत नहीं किया।

— जारेड अपडेटाइक

@ जारेड, काफी नहीं। इसकी तुलना सॉडुकस को हल करने में करें। इसे हल करने के लिए आप कई तरह की तरकीबें अपना सकते हैं, लेकिन बिना पीछे किए इसे अच्छी तरह से करने में समय और अभ्यास लगता है।

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

— कष्टप्रद_सुबह

Answer 11

मैं सिर्फ रिचर्ड फेनमैन का एक वीडियो देख रहा था, जिसमें लोग सोच रहे थे कि वास्तव में लोगों के दिमाग में पूरी तरह से अलग तरीके कैसे हो सकते हैं।

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

मुझे विवरणों को याद रखने में भी परेशानी होती है और OO को एक महान संगठनात्मक सहायता मिली - सबरूटीन्स की शिथिल-व्यवस्थित सूची के माध्यम से स्कैनिंग की तुलना में कार्यक्षमता खोजने में बहुत आसान है।

मेरे लिए OO एक बहुत बड़ा लाभ था, लेकिन अगर आप उसी तरह की कल्पना नहीं करते हैं या उच्च-स्तरीय वास्तुकला नहीं करते हैं, तो यह संभवतः व्यर्थ और कष्टप्रद है।

Comments

+1 मैं उसी तरह महसूस करता हूं, लेकिन रूबी मिश्रण सहित विपरीत दिशा में बहुत सारे पुश हैं ... जो आपको एहसास दिलाता है कि हर किसी के लिए सख्त नहीं है।

— दानो रोसेनस्टार्क

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

— बिल के

मुझे लगता है कि यह अधिक प्राकृतिक नामकरण सम्मेलनों को प्रोत्साहित करने में भी मदद करता है। अब आपको फ़ंक्शन के प्रकार को फ़ंक्शन नाम (जैसे INSTR) में एनकोड करने की आवश्यकता नहीं है - क्योंकि नाम टाइप से जुड़ा हुआ है (जैसे string::find)

— केन ब्लूम

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

— बिल के

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

— केन ब्लूम

Answer 12

मैं GW-बेसिक और टर्बो पास्कल OO के लिए पेश किए जाने से पहले एक निष्पक्ष बिट प्रोग्रामिंग, तो शुरू में यह किया था गए में मेरे सिर से करते हैं।

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

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

Comments

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

— डैरनव

Answer 13

मुझे नहीं लगता कि यह समझना मुश्किल है, लेकिन यह हो सकता है कि क्वेरी करने वाले बहुत सारे प्रोग्रामर अवधारणा के लिए नए हैं, प्रक्रियात्मक भाषाओं से आ रहे हैं।

मैंने बहुत से लोगों को देखा / पढ़ा है (कम से कम मंचों में) ओओपी से एक 'परिणाम' की तलाश में। यदि आप एक प्रक्रियात्मक प्रोग्रामर हैं जो वापस नहीं जाते हैं और अपने कोड को संशोधित करते हैं तो लाभ को समझना मुश्किल हो सकता है।

इसके अलावा, वहाँ बहुत बुरा ओओपी है, अगर लोग पढ़ रहे हैं / देख रहे हैं तो यह देखना आसान है कि उन्हें यह मुश्किल क्यों लग सकता है।

IMO आपको तब तक इंतजार करना होगा जब तक कि वह 'क्लिक' नहीं करता या वास्तविक ज्ञान वाले किसी व्यक्ति द्वारा सिखाया जाता है, मुझे नहीं लगता कि आप जल्दी कर सकते हैं।

Comments

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

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

Answer 14

मुझे लगता है कि OOP का कारण बहुतों के लिए कठिन है क्योंकि उपकरण वास्तव में इसे सुविधाजनक नहीं बनाते हैं।

कंप्यूटर की भाषा आज कंप्यूटर में चल रही एक अमूर्तता है।

OOP सार का प्रतिनिधित्व करने के लिए एक सार तरीका है।

तो हम एक अमूर्त के साथ अमूर्त बनाने के लिए एक अमूर्त का उपयोग कर रहे हैं। इसमें यह जोड़ें कि हम जो अमूर्त कर रहे हैं वह आमतौर पर बहुत जटिल शारीरिक / सामाजिक बातचीत है और, ठीक है, कोई आश्चर्य नहीं।

Answer 15

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

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

Comments

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

— कर्क ब्रॉडहर्स्ट

इसमें कोई शक नहीं कि यह प्रक्रियात्मक प्रोग्रामिंग से सोचने का एक अलग तरीका है। लेकिन कई लोग जो कहते हैं, उसके विपरीत, यह A) सोच का अप्राकृतिक तरीका नहीं है, और B) जटिल है। मुझे लगता है कि यह अच्छी तरह से नहीं पढ़ाया जाता है।

— कष्टप्रद_संकट

Answer 16

प्रेरणा। जब आप क्यों नहीं देखते हैं, तो कुछ सीखना मुश्किल होता है, और यह भी कि जब आपने जो किया उसे देख नहीं सकते और यह समझ सकते हैं कि आपने इसे सही किया है या नहीं।

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

Comments

लोग हमेशा सिंगलटन के बारे में बात करते हैं, लेकिन फिर उसे हमेशा पार्टी में आमंत्रित किया जाता है। लेकिन यह सच है, वह गैर-ऊ ऊ डीपी है।

— दान रोसेनस्टार्क

Answer 17

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

दूसरी ओर, यदि आप सोचते हैं, जैसा कि मेरे कई जावा छात्रों ने किया, "हम यह क्यों सीख रहे हैं, यह सिर्फ एक सनक है," यह सीखना व्यावहारिक रूप से असंभव है। यह अधिकांश प्रौद्योगिकियों के साथ सच है।

Comments

ऊ एक सनक? कितने साल अपने छात्रों को कर रहे हैं - मुझे लगता है यह "सनक" से पुराना है वे कर रहे हैं (प्रथम OO मैंने किया था - मैं जानता था कि मैंने किया था - के बारे में 1983/4 में सिमुला था और सिमुला उस बिंदु पर नया नहीं था)

— Murph

@ मर्फ़ यह लगभग 2004-2005 में था और छात्र निश्चित रूप से 45-50 से अधिक थे (इबेरिया में पेशेवर प्रोग्रामर)।

— दान रोसेनस्टार्क

ठीक है, मैं यह देख सकता हूं कि वे ओओ चीज की शुरुआत में कैसे चूक गए होंगे। लेकिन 2004/5 तक हम अच्छी तरह से .NET में थे जो कि OO की दीवार से बहुत अधिक दीवार है (-: विकास में कुछ ऐसी चीजें हैं जिनका वर्णन कुछ लोग कर सकते हैं, लेकिन जो फिजूल नहीं हैं वे जल्दी से अच्छे सामान में विकसित हो जाते हैं

— मर्फ़

@ ईमानदार होने के लिए ये लोग मेनफ्रेम प्रोग्रामर थे जिन्हें वे जावा में बदलने की कोशिश कर रहे थे। यह वास्तव में एक मनोरंजक और अनूठा अनुभव था (मेरे जावा ट्रेनर दिनों के लिए सामान्य किराया नहीं)। यह है सच यह है कि वे देखा था बहुत सी बातें आते हैं और जाते हैं, लेकिन स्पष्ट रूप से OO एक सनक से अधिक है। एक अलग नोट पर: मैं उम्मीद कर रहा था कि यह यूनिट टेस्टिंग चीज एक सनक के रूप में खत्म हो जाएगी, लेकिन अब मुझे पता चला है कि मेरे पास लिखने के लिए बहुत सारे यूनिट टेस्ट हैं ... :)

— डैन रोसेनस्टार्क

Answer 18

भले ही आप कौन सा प्रतिमान (OOP, कार्यात्मक, आदि) चुनते हैं, कंप्यूटर प्रोग्राम लिखने के लिए, आपको यह जानना होगा कि आपका प्रोग्राम क्या कदम उठाएगा।

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

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

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

Answer 19

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

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

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

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

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

Comments

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

— गंगनुस

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

— dsimer

यह भाषा पर निर्भर करता है - SmallTalk में दूरी (और सब कुछ) एक वस्तु है। लेकिन C # में आपने उल्लेख किया है कि यह बुरा होगा।

— गंगनुस

Answer 20

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

सहमत है कि डिजाइन पैटर्न कम से कम ओओपी के समानांतर होना चाहिए।

Answer 21

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

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

Comments

वाह उस हिस्से का कोई मतलब नहीं है। "कक्षाओं और वस्तुओं के इंस्टेंस आदि के बीच प्रक्रिया करने के लिए सब कुछ बहुत ही सारगर्भित और कठिन था। लेकिन एक बार OOP मिलते ही प्रोग्रामिंग लैंग्वेज को समझना बहुत आसान हो गया। लेकिन यह थोड़े पहले ही उन कनेक्शनों को बनाने के लिए एक छलांग लगा लेता है"

Answer 22

विधि

अच्छी OOP समझ = अच्छी Mentor या अच्छी पुस्तकें या दोनों + व्यक्तिगत रुचि + अभ्यास।

व्यक्तिगत रुचि

मेरे व्यक्तिगत अनुभव से, व्यक्तिगत रुचि में मानसिक या अच्छी किताबों या दोनों संयुक्त से सही आदानों के साथ प्रक्रियात्मक प्रोग्रामिंग से ओओपी तक पुल को पार करने का एक लंबा रास्ता तय होता है ।

अभ्यास, अभ्यास और अभ्यास

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

जैसा कि कहा जाता है "कड़ी मेहनत का कोई विकल्प नहीं है और सफलता का कोई शॉर्टकट नहीं है।"

सौभाग्य!