ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सीखने से पहले हमें प्रोसीजरल प्रोग्रामिंग क्यों सीखनी चाहिए [बंद]

Question

मैं अभी 4 साल में एक आईटी विश्वविद्यालय में हूँ, और जब मैं अपने प्रोफेसर से इस विषय पर बात करता हूँ तो वह मेरी राय को अस्वीकार कर देता है और मुझे बहुत भारी आलोचना देता है (मेरे विश्वविद्यालय में, हमें C (ANSI) (प्रोसेडुरल में पढ़ाया जा रहा था) प्रोग्रामिंग कक्षा - विश्वविद्यालय में 1 वर्ष में) C ++ से पहले (2 वें वर्ष में OOP वर्ग में) और अन्य ...

लेकिन 13 साल की उम्र में मेरे भाई को मेरे द्वारा पढ़ाया गया था, पहले जावा और कुछ नहीं। अब, वह लगभग वह सब कुछ कर सकता है जो एक सामान्य द्वितीय-वर्ष का छात्र जावा के साथ कर सकता है।

आप के लिए, मैं जानना चाहता हूँ कि आपको क्यों लगता है कि हमें पहले प्रक्रियात्मक प्रोग्रामिंग सिखाई जानी चाहिए।

Comments

क्योंकि असेंबलर में ऑब्जेक्ट्स नहीं हैं।

यह ऐसा है कि क्यों हमें कैलकुलेटर का उपयोग करना सीखने से पहले ठीक से गणना करने के लिए सिखाया जाना चाहिए।

क्योंकि ऑब्जेक्ट ओरिएंटेड डिज़ाइन त्रुटिपूर्ण है। प्रोग्राम व्यवहार का एक संग्रह है जो डेटा पर काम करते हैं। ऑब्जेक्ट अक्सर अनावश्यक जटिलता का परिचय देते हैं। "कैसे डिजाइन करने के लिए कार्यक्रम पढ़ें: प्रोग्रामिंग और कम्प्यूटिंग के लिए एक परिचय"।

जैसा कि किसी और के द्वारा रखा गया है, "OOP वाले नए प्रोग्रामर को विचलित न करें": prog21.dadgum.com/93.html - मूल रूप से OOP नए प्रोग्रामर्स को फंडामेंटल सिखाने के रास्ते में है। आप उन्हें एक ही समय में दो कठिन अवधारणाएँ सिखा रहे हैं।

— जॉन रिप्ले

@juxstapose - ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग कहना अनावश्यक जटिलता का परिचय देता है, जैसे हम कहते हैं कि हमें स्टील के एक ब्लॉक से वाहनों को चलाना चाहिए। एकदम मेरे विचार।

Answer 1

त्वरित सारांश:

1. क्योंकि वास्तविक दुनिया में, जल्दी या बाद में, आपको प्रक्रियात्मक कोड के साथ काम करना होगा।

2. चूँकि प्रोसीडुरल लैंग्वेज सिर्फ एक विकल्प के बजाय ऑब्जेक्ट ओरिएंटेड लैंग्वेज के लिए एक एक्सटेंशन, या एक इंट्रोडक्शन की तरह काम कर सकते हैं।

3. जवाब देने के लिए पूरक 2. क्योंकि ओओपी प्रक्रियात्मक प्रोग्रामिंग की तुलना में अधिक जटिल है, इसलिए पहले प्रक्रियात्मक प्रोग्रामिंग सीखना बेहतर है।

4. क्योंकि वास्तविक दुनिया में, प्रोग्रामर के साथ काम करते हैं, और समस्याओं को हल करने के लिए कई तरीकों को मिलाते हैं, एकेए "मल्टीपरेडिग्म प्रोग्रामिंग", न केवल एक प्रतिमान।

5. अधिकांश प्रोग्रामिंग भाषाएं बहुस्तरीय हैं, कुछ स्तर पर, यहां तक ​​कि, अगर उनके डिजाइनर या आम डेवलपर्स, इसके विपरीत कहते हैं।

6. [नई] क्योंकि मॉड्यूलर प्रोग्रामिंग जो आमतौर पर मिश्रित और प्रक्रियात्मक प्रोग्रामिंग के साथ उलझन में है, को OOP पर लागू किया जा सकता है इसलिए प्रश्न को "हम ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सीखने से पहले हमें मॉड्यूलर प्रोग्रामिंग क्यों सीखना चाहिए" के रूप में पढ़ा जा सकता है

विस्तारित बोरिंग विवरण:

प्वाइंट 1 बहुत स्पष्ट है, आगे स्पष्टीकरण नहीं।

पॉइंट 2, क्लासेस, इनहेरिटेंस, पॉलिमॉर्फिस्म, इंटरफेसेस, इत्यादि ...

बिंदु 3, मैं प्रक्रियात्मक पास्कल को कोड करता हूं इससे पहले कि मैंने ऑब्जेक्ट ओरिएंटेड पास्कल सीखा, जब मैं वहां गया तो मैंने कहा: "देखो, कक्षाएं छोटे प्रक्रियात्मक कार्यक्रमों की तरह हैं ... ... और आप उन्हें एक दूसरे से बात कर सकते हैं, शांत !!! "।

मैंने उन लोगों से वही सुना जो सादे सी से सी प्लस प्लस में गए थे।

बिंदु 4, अधिकांश बार प्रोग्रामर कई प्रोग्रामिंग तकनीकों या प्रतिमानों को जोड़ते हैं, या किसी समस्या को हल करने के तरीके। कार्यात्मक, प्रक्रियात्मक, OOP, तार्किक।

यहां तक ​​कि जावा "प्योर ओओ" भी सादे ऑब्जेक्ट प्रोग्रामिंग के रूप में नहीं है जैसा कि यह कहता है।

+1 बिंदु "संरचित प्रोग्रामिंग" के बजाय "प्रक्रियात्मक प्रोग्रामिंग" के लिए। या मॉड्यूलर प्रोग्रामिंग। ये महत्वपूर्ण है।

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

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

कई बार, मैं एक OO कोड पढ़ सकता हूं और बता सकता हूं कि प्रोग्रामर ने OOP से पहले स्ट्रक्चर्ड प्रोग्रामिंग सीख लिया, क्योंकि कोड स्पष्ट और व्यवस्थित है।

और मॉड्यूलर प्रोग्रामिंग के लिए, मैंने कई ऐप देखे हैं। C ++ और PHP में जो मॉड्यूल का उपयोग नहीं करता है। *

Answer 2

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

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

Comments

+1 - वहाँ इरादे का विरोधाभास ... "अधिक

@स्पेसmoses - वास्तव में नहीं, कुछ अधिक ही सारगर्भित है, चर्चा जितनी आसान है लेकिन जितनी कठिन चर्चा की जा रही है उसकी वास्तविकता को समझना उतना ही कठिन है।

सहमत, मैं अब आपकी बात देखता हूं।

— ses011

Answer 3

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

Comments

लेकिन कार्य + राज्य = वस्तुएं

— Dan D.

ऑब्जेक्ट ओरिएंटेशन अक्सर रखरखाव को अधिक कठिन बना देता है क्योंकि यह कोड आधार को फुलाता है। जावा-आधारित प्रणाली उस समुदाय में पाए जाने वाले OO शुद्धता और डिज़ाइन पैटर्नाइटिस के स्तर के कारण बनाए रखने के लिए एक बुरा सपना है।

— बिट-ट्विडलर

"डिजाइन पैटर्न उस समुदाय में पाए जाते हैं" - "जावा समुदाय" में एक निजी समस्या की तरह लगता है अगर वह आपका रुख है।

— ses011

@ डी डी: ऑब्जेक्ट ओरिएंटेशन किसी ऑब्जेक्ट में फ़ंक्शंस और स्टेट को मिलाने से कहीं अधिक है ...

— मार्जन वेनमा

@Spacemoses: मैं किसी भी विकास समुदाय की कि किस सिद्धांत को गले नहीं करता है के साथ एक समस्या है। किसी समस्या का सबसे अच्छा समाधान अक्सर सबसे सरल समाधान होता है।

— बिट-ट्विडलर

Answer 4

तुम नहीं।

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

मैंने कई बार अपने आप से इस पर बहस की है, और मैं अंत में इस निष्कर्ष पर पहुंचा हूं कि यह वास्तव में इस बात पर निर्भर करता है कि आपका शिक्षक आपको अवधारणाओं को कितनी अच्छी तरह सिखाता है।

कोई एकल उत्तर नहीं है क्योंकि:

• कुछ प्रक्रियात्मक जैसे सी (या यहां तक ​​कि विधानसभा) के साथ शुरू करना एक अच्छा विकल्प हो सकता है, क्योंकि आप सीखते हैं कि कंप्यूटर वास्तव में कैसे काम करते हैं

• कुछ ऑब्जेक्ट-ओरिएंटेड जावा से शुरू करना एक अच्छा विकल्प हो सकता है, क्योंकि वास्तविक जीवन में OOP सीखना और लागू करना अपेक्षाकृत आसान है, और क्योंकि यह आपको ** बनाने के बारे में सिखाता है

• योजना जैसे कार्यात्मक प्रोग्रामिंग के साथ शुरू करना एक अच्छा विकल्प हो सकता है क्योंकि यह आपको अधिक सारगर्भित (चर के बजाय कार्यों के संदर्भ में) सोचने के बारे में सिखाता है, जो अंततः आपको एक बेहतर प्रोग्रामर बनाता है।

यदि आपका शिक्षक इसे अच्छी तरह से नहीं सिखाता है, तो यह वास्तव में मायने नहीं रखता है कि आप क्या शुरू करते हैं; वे बहुत अधिक एक ही बाहर बारी हूँ।

Comments

+1 धमाके पर और मुझे विश्वास नहीं हो रहा है कि मुझे इसे खोजने के लिए बहुत सारे खराब उत्तरों के माध्यम से स्क्रॉल करना होगा!

— जे.के.

मुझे वास्तव में थोड़ी देर के लिए गणित के कार्यों को करने में परेशानी हुई, क्योंकि मैंने पहले कुछ कोडिंग सीखी थी, और एक फ़ंक्शन की अवधारणा जो 'मुझे' करने के बजाय 'चकित' करती है। : 3

— StarWeaver

Answer 5

एक भाषा C ++, Java या C # जैसी ऑब्जेक्ट ओरिएंटेड हो सकती है। और आप इन भाषाओं से शुरुआत कर सकते हैं। लेकिन बात यह है कि इन ओओ भाषाओं के साथ भी, आपको पहले प्रक्रियात्मक प्रोग्रामिंग सीखना होगा, फिर ओओपी। मुझे लगता है, आपके द्वारा आपके भाई के साथ भी ऐसा ही किया गया था।

Comments

+1 ठीक है। हर OOP विधि एक छोटी प्रक्रियात्मक कार्यक्रम है। आप कैसे छोटे टुकड़े (प्रकार, शाब्दिक मूल्यों, चर, ऑपरेटर, गठबंधन करने के लिए पता नहीं है =काम, if, forबड़ा टुकड़े (विधि) में, आदि), OOP समझ कैसे आप कभी भी आशा कर सकते हैं। अधिकांश कौशल के साथ, बहुत स्मार्ट, प्रेरित, और / या एक-एक निर्देश तक पहुंच होने से आप एक साथ कई, संबंधित विषयों को सीख सकते हैं।

— डेविड हरकनेस

Answer 6

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

इस तरह, छात्र एक ही समय में विज्ञान (एल्गोरिदम, डेटा संरचनाएं) और इंजीनियरिंग के एक बिट (स्रोत-> ऑब्जेक्ट-> मशीन संकलन, वॉन-न्यूमन (संभावना) वास्तुकला) सीख सकते हैं।

O ++, C ++ / obj-C के माध्यम से एक कोड संगठन पैटर्न का परिचय देता है, जिसे सीखना एक और बात है। यह कुछ अधिक कठिन ऊपर अवधारणाओं को सीखने में मदद कर सकता है।

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

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

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

Answer 7

OOP ऑब्जेक्ट्स की हिम्मत प्रक्रियात्मक प्रोग्रामिंग से बनी होती है।

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

आप वास्तव में वैसे भी एक परिचयात्मक वर्ग में ओओपी नहीं सीखेंगे, यह सिर्फ वाक्यविन्यास होगा - सीधे ओओपी में कूदने से चीजें पहले से ही समझ में आ सकती हैं (पहले)।

OOP कक्षाओं को बनाने के कुछ सिंटैक्स की घोषणा करने के बारे में नहीं है, यह डेटा संरचनाओं, डिज़ाइन पैटर्न, बहुरूपता, वंशानुक्रम और संरचना के बारे में है।

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

अगर मैं होता तो मैं निम्नलिखित पुस्तकों में से कुछ उठाता: सी प्रोग्रामिंग लैंग्वेज , द जावा प्रोग्रामिंग लैंग्वेज , डिज़ाइन पैटर्न , गैंग ऑफ़ फोर और पैटर्न हैचिंग । यदि मैं C / C ++ के बारे में गंभीर था, तो मैं निश्चित रूप से The C Programming Language की एक प्रति चुनूंगा।

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

आपको SQL सीखने के लिए भी समय निकालना चाहिए, Oracle MySQL Postgresql और MSSQL में सिंटैक्स के बारे में बहुत कुछ है, लेकिन अगर मुझे सिर्फ एक सीखने के लिए खुद को id चुनना है Postgresql सिर्फ इसलिए कि यह GPL के बजाय BSD लाइसेंस प्राप्त है (आपको एक तुलना दिखनी चाहिए और जीपीएल / बीएसडी लाइसेंस पर इसके विपरीत)

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

Comments

मेरे पास '89 से C का उपयोग करने वाला एक शिक्षक था, लेकिन यह c '99 की अपेक्षा करने वाले एक माइक्रोचिप के लिए था। तब वह अन्य शिक्षक 'c ++' का उपयोग कर रहा था, लेकिन STL या टेम्पलेट के बिना। हो सकता है कि उनमें फंक्शन पॉइंटर्स के साथ स्ट्रक्चर्स भी हों।

— एप-इनोगो

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

— बिट-ट्विडलर

दो डाउनवॉच ouch। यह देखा कि एक आ रहा है = पी मुझे अजीब है, हालांकि राय मूल रूप से एक पुराने प्रोग्रामर से आई है जिसने मुझे खराब शिक्षण से उबरने में मदद की। @ एप: हमारे सीएस विभाग के प्रमुख ने हमें 2004 में एक साल के लिए एक्सबीडी (अपनी 'शिक्षण' शैली से मेरी चिंताओं को कम करने के लिए COBOL सिखाने की कोशिश की थी, मुझे इस बात से कोई आपत्ति नहीं है क्योंकि मैं बिक्री के कुछ बिंदुओं पर काम कर सकता हूं। मशीनें लोल लेकिन गीज़ ... गंभीरता से?)

— गेरेट क्लैबोर्न

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

— गार्ट क्लैबोर्न

@ बिट-ट्विडलर: हाँ, लेकिन यह एक परिचयात्मक पाठ्यक्रम नहीं था। यह डेटाबेस डिजाइन में एक 4 वें वर्ष का उन्नत पाठ्यक्रम था, और हमें c ++ का उपयोग करना चाहिए था। पिछले पाठ्यक्रमों के साथ उच्च स्तर पर c ++ का अनुभव करने के बाद यह गलत लगा।

— एप-इनैगो

Answer 11

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

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

Comments

"ओओ प्रोग्रामिंग प्रक्रियात्मक प्रोग्रामिंग की समस्याओं को हल करने के लिए आया था।" यह लक्ष्य था, लेकिन OO ने जितनी समस्याएं हल कीं, उतनी ही समस्याएं पैदा कीं।

— बिट-ट्विडलर

@ बिट-ट्विडलर: बहुत बड़ी कहानी। शैक्षणिक पहलू पर ध्यान केंद्रित करना (या इसे कम करना), यह एक मामला बनाता है: हमारे पास यह क्या था, हमने इसे कैसे बेहतर बनाया: (आप इस पर बहस करते हैं कि यह बेहतर है या नहीं)

— दिमित्रियोस मिस्ट्रिटिस

Answer 12

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

Comments

-1 भ्रामक - जब मैंने एक धागा (Google खोज के माध्यम से) देखा, जिसमें दावा किया गया था कि CMU ने अपने पहले साल के CS पाठ्यक्रम से OOP गिरा दिया और इसे कार्यात्मक प्रोग्रामिंग से बदल दिया, आधिकारिक CMU पाठ्यक्रम की शुरुआत ऐलिस प्रोग्रामिंग भाषा से होती है, जो ऑब्जेक्ट- उन्मुख [देखें enr-apps.as.cmu.edu/assets/SOC/CS_SPRING.htm]

— स्टीवन ए। लोव

@ davidk01: (1) उत्तर में तथ्यात्मक रूप से गलत दावा। (2) "ऐलिस एक स्वतंत्र रूप से उपलब्ध शिक्षण उपकरण है जो एक छात्र के ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए पहला एक्सपोज़र तैयार किया गया है " alice.org से

— स्टीवन ए। लोव

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

— davidk01

@ davidk01: उत्कृष्ट लिंक, धन्यवाद। उस लेख में उद्धृत समिति के पेपर से "यद्यपि वस्तु-उन्मुख प्रोग्रामिंग (अपने असंख्य रूपों में) औद्योगिक सॉफ्टवेयर विकास में एक प्रमुख विषय बना हुआ है, परिचयात्मक स्तर पर ऑब्जेक्ट-उन्मुख भाषाओं का उपयोग, जैसे कि परिचयात्मक स्तर पर काफी जटिलता और विचलितता का परिचय देता है। परिचयात्मक स्तर पर मुख्य लक्ष्यों से । यह प्रारंभिक स्तर पर मूल बातें पर अधिक ध्यान केंद्रित करने की अनुमति देने के लिए बाद में पाठ्यक्रम में ओओ डिजाइन और कार्यान्वयन पद्धति की पूरी कवरेज देना बेहतर लगता है। " [जोर मेरा] ...

— स्टीवन ए लोव

@ davidk01: असहमति से सहमत होकर मुझे खुशी है। यदि आप चाहें तो मुझे पांडित्य कहें, लेकिन मेरे लिए परिचयात्मक स्तर के जोर को बदलने और "उनके पूरे ओओपी पाठ्यक्रम को बाहर फेंकने" के बीच एक महत्वपूर्ण अंतर है। मैं मुश्किल से एक "व्यापक परिवर्तन" ;-) परिचयात्मक कक्षाओं के दायरे को कम करने फोन करता हूँ

— स्टीवन ए लोव