क्या आपत्तिजनक उन्मुख प्रोग्रामिंग प्रतिमान पुराना है क्योंकि यह मॉड्यूलर और विरोधी समानांतर है? [बन्द है]


23

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

और उन्होंने दावा किया कि:

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

ओओपी को एंटी-मॉड्यूलर और एंटी-समानांतर क्यों मानते हैं?



14
Buhwaaaah ?! OO प्रक्रियात्मक की तुलना में प्रतिरूपकता और समानता को आसान बनाता है और FP के लिए पारस्परिक रूप से अनन्य नहीं है। मुझे उलझन में रंग।
मैट एलेन

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

4
@ मैट एलेन: ओओपी एफपी के साथ निश्चित रूप से पारस्परिक रूप से अनन्य है। एफपी को कई प्रमुख अवधारणाओं पर समर्पित किया गया है जिनमें से एक उत्परिवर्ती राज्य की अनुपस्थिति है। ओओपी उत्परिवर्तित राज्य के अस्तित्व पर समर्पित है जिसकी पहुंच "वस्तुओं" में लपेटकर नियंत्रित की जाती है। उत्परिवर्तनीय अवस्था और अपरिवर्तनीय अवस्था, परिभाषा के अनुसार परस्पर अनन्य रूप से विशिष्ट हैं। हां, यह सच है कि आप कई ओओपी भाषाओं के साथ एक कार्यात्मक शैली में कार्यक्रम कर सकते हैं, लेकिन यह एक एफपी भाषा का उपयोग करने के समान नहीं है। और हाँ यह सच है कि सभी FP भाषाएँ शुद्ध नहीं हैं। यह नहीं कह रहा है कि एफपी ओओपी के साथ संगत है, हालांकि।
JUST MY सही OPINION

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

जवाबों:


30

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

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

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

वंशानुक्रम भी समस्याग्रस्त है (जैसे फ्रैजाइल बेस क्लास समस्या ) और (उपप्रकार) बहुरूपता एक को कई वर्गों के बीच एक एल्गोरिथ्म के कार्यान्वयन को पूरा करने के लिए फुसलाता है, जहां परिवर्तन पूरे वंशानुक्रम श्रृंखला (ऊपर और नीचे!) के माध्यम से तरंग कर सकते हैं ।

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

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


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

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

@ davidk01 उदाहरण के लिए जाओ। यह ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग को सपोर्ट करता है और इसमें कंसिस्टेंट प्राइमरी बहुत बढ़िया है। इससे भी महत्वपूर्ण बात यह है कि यह वास्तव में समवर्ती प्रोग्रामिंग के लिए पूरी तरह से कार्य कर रहा है।
वेबर 2

19

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

यह लेख विवादास्पद नहीं है। विवाद में परीक्षा, तर्क और चर्चा शामिल है। यहाँ आपके पास कुछ अज्ञानी अकादमिक हैं जो केवल एक ही बयान में दो बुनियादी आरोप लगाते हैं, बिना किसी तर्क के।

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

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

OOP के साथ समस्या यह है कि कुछ लोग वास्तव में इसे उस अर्थ में समझते हैं जो एलन के ने इसे परिभाषित किया था।

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

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

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


1
संदेश पास करने के लिए +1, और 'जावा के साथ' के लिए +1। दुर्भाग्य से अगर उन्होंने जावा को हटा दिया, तो वे इसे C # से बदल देंगे और अपनी विरासत जारी रखेंगे।
gbjbaanb

आलोचकों के लिए @ back2dos +1, जावा के लिए -1। निश्चित रूप से, स्मॉलटाक जावा की तुलना में "बहुत अधिक ओओ" है, लेकिन इसका उपयोग कौन करता है? ऑब्जेक्टिव-सी शुरुआती के लिए कठिन है जैसे सी है।
मातरिनस

@maaartinus: आप स्क्वीक को व्यापक रूप से शैक्षिक और शैक्षणिक क्षेत्र में उपयोग करने के लिए पाएंगे, यदि वह आपके प्रश्न का उत्तर देता है। जावा के लिए भी: आप इसे पसंद कर सकते हैं, मैं नहीं कर सकता। कॉफी पसंद है, यह व्यक्तिगत पसंद की बात है और इस पर चर्चा करने का कोई मतलब नहीं है। हालाँकि, OOP के परिचय के लिए जावा अनुपयुक्त है, IMHO जावा की प्रकृति और OOP की अवधारणा का एक निर्विवाद निहितार्थ है और यही मैंने कहा था। जावा की लोकप्रियता दूर नहीं होगी। जैसा कि C के लिए, मेरा सुझाव है कि आप joelonsoftware.com/articles/ThePerilsofJavaSchools.html पढ़ें ।
back2dos

@ back2dos स्क्वीक का उपयोग इन क्षेत्रों में किया जा सकता है, लेकिन विश्वविद्यालय में मैंने एमएल सीखा है। दोनों उद्योग में समान रूप से अनुपयोगी हैं और दोनों अपनी अवधारणाओं के कारण सीखने लायक हैं। बताया गया लेख जोएल का अब तक का सबसे बुरा लेख है, यह बहुत लंबा है और पहली नजर में यह संदेश सीगफॉल्ट से निपटने का महत्व प्रतीत होता है। : D मैं वास्तव में OOP सिखाने के लिए जावा का सुझाव दूंगा।
मातरिनस

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

12

आपको हर धारी के जोनल मिलते हैं।

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

बीस साल से अब कोई शक नहीं है कि हम कार्यात्मक प्रोग्रामिंग के खिलाफ कुछ अन्य प्रतिक्रिया करेंगे।


1
वहाँ पहले से ही है!
क्वांट_देव

1
++ "आपको हर स्ट्राइप के ज़ीलोट्स मिलते हैं।" मैं एक अकादमिक था, और मेरा अनुभव यह था । शिक्षाविदों को अपने छात्रों को प्रभावित करने के लिए उत्तेजक राय देना पसंद है।
माइक डनलवेई

5

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

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

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

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


4

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

प्रस्तावित पाठ्यक्रम एक कक्षा में कार्यात्मक प्रोग्रामिंग, दूसरी कक्षा में अनिवार्य (प्रक्रियात्मक) प्रोग्रामिंग और दूसरी कक्षा में डेटा संरचनाएं सिखाएगा। एक बार जब एक नए व्यक्ति को इन 3 चीजों में महारत हासिल हो जाती है, तो उसे ओओपी सीखने के लिए तैयार रहना चाहिए।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.