गो जैसी भाषा पर क्लासिक ओओपी के लाभ

Question

मैं भाषा डिजाइन के बारे में बहुत सोच रहा हूं और "आदर्श" प्रोग्रामिंग भाषा के लिए कौन से तत्व आवश्यक होंगे, और Google के गो का अध्ययन करने से मुझे बहुत अधिक सामान्य ज्ञान पर सवाल उठाने का नेतृत्व किया गया है।

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

क्या O ++ के बारे में कुछ ऐसा है जो C ++ और Java और C # में लागू किया गया है, जो स्वाभाविक रूप से अधिक सक्षम, अधिक रख-रखाव वाला, किसी भी तरह से अधिक शक्तिशाली है जिसे आपको गो जैसी भाषा में जाने पर छोड़ना होगा? इस नए प्रतिमान का प्रतिनिधित्व करने वाली सादगी हासिल करने के लिए आपको क्या लाभ देना है?

EDIT
ने "अप्रचलित" प्रश्न को हटा दिया, जिससे पाठकों को लगने लगा कि वे इससे अधिक त्रस्त हैं और इससे प्रभावित हुए हैं।

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

Comments

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

— जेमी टेलर

जब आप OOP के लिए Google मृत होते हैं, तो कुछ दिलचस्प रीड होते हैं । जब

— ओओपी की

ओओपी में इतना कम मूल्य है कि यह आपका समय बर्बाद करने के लायक नहीं है।

— SK-तर्क

मैं पिछली टिप्पणी से सहमत हूं कि ओओपी पर बहुत अधिक ध्यान केंद्रित नहीं है। OOP के अलावा C ++ या Java का मतलब नहीं है। Abt को ltu.org पर पढ़ने की कोशिश करें

— AndreasScheinert

C ++, Java और C # "क्लासिक" OOP भाषाएँ नहीं हैं। यदि कोई ओओपी भाषा है, तो मुझे लगता है कि यह स्मॉलटाक है।

— केविन क्लाइन

Answer 1

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

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

Comments

"जरूरी नहीं कि सबसे अच्छा एक" के लिए +1। एलन के का हवाला देते हुए: "मैंने ऑब्जेक्ट-ओरिएंटेड शब्द का आविष्कार किया है, और मैं आपको बता सकता हूं कि मेरे पास सी ++ नहीं था।" (और न ही उसके पास C # और / या जावा था, मैं विनम्रतापूर्वक अनुमान

— लगाऊंगा

@herby मैंने देखा है कि यह सुझाव दिया गया है कि एजेंट-सिस्टम (Erlang कैसे काम करता है) OOP के लिए एलन का के अंतिम इरादे के करीब हैं।

— कोडेक्सअर्बनम

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

— वेटिन

हां, मेरा मतलब यह है कि इसमें जावा अर्थ में कक्षाएं नहीं हैं

— एंड्रिया

Answer 2

इस नए प्रतिमान का प्रतिनिधित्व करने वाली सादगी हासिल करने के लिए आपको क्या लाभ देना है?

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

क्या ऐसी प्रणाली OOP की अवधारणा को अप्रचलित करती है?

नहीं। जब तक आप निर्देशों की सूची, या नियमों के एक घोषित सेट, या फ़ंक्शन की एक विस्तृत श्रृंखला के बजाय 'ऑब्जेक्ट्स' के संदर्भ में कार्यक्रम बना सकते हैं ... कार्यान्वयन कोई फर्क नहीं पड़ता। इसी तरह, टाइप सिस्टम को बदलना आम OO सिद्धांतों में से किसी को भी अमान्य नहीं करता है।

आप अभी भी आधार प्रकार पर काम कर सकते हैं और इसके वास्तविक प्रकार की परवाह नहीं कर सकते हैं। आप अभी भी उन्हें संशोधित किए बिना प्रकारों का विस्तार कर सकते हैं। आप अभी भी केवल एक ही काम कर सकते हैं। आप अभी भी ठीक अनाज इंटरफेस की आपूर्ति कर सकते हैं। आप अभी भी अपने प्रकारों के लिए सार की आपूर्ति कर सकते हैं।

एक भाषा कैसे अनुमति देती है जो वास्तव में मायने नहीं रखती है।

Comments

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

— Jan Hudec

Answer 3

मुझे लगता है कि OOP के बारे में आपका विचार थोड़ा हटकर है:

मैंने 'ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग' शब्द का आविष्कार किया और यह {जावा और सी ++} वह नहीं है जो मेरे दिमाग में था।
- एलन के ।

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

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

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

Comments

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

— 21

@tylerl: आप कम से कम दो प्रश्नों को एक में उलझा रहे हैं। एक यह है कि क्या संरचनात्मक सबटाइपिंग नाममात्र सबटाइपिंग से बेहतर है। अन्य एक मूल रूप से है, चाहे रचना विरासत से बेहतर हो। ये प्रश्न पारस्परिक रूप से रूढ़िवादी हैं। मुझे लगता है कि अंततः "सर्वश्रेष्ठ" भाषा आपके लिए यह विकल्प नहीं बनाती है। मैं अनुमान लगाता हूँ कि Go में बस मुद्दों का एक अलग सेट है, लेकिन हम देखेंगे कि Google उन विशेषताओं को "वापस" जोड़ता है या नहीं।

— back2dos

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

— एरिक अलाप

Answer 4

OOP अप्रचलित नहीं है।

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

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

Comments

मुझे लगता है: कई जगहों पर थकाऊ। एक फायदा नहीं है, वास्तव में।

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

@AndreasScheinert क्यों यह एक फायदा नहीं होगा?

— सिमोन बेरगॉट

क्योंकि निर्णय लेने के लिए आपको कम से कम 1 विकल्प पर समान रूप से अच्छा जानना चाहिए। यह एक आदत का मुद्दा है, लोग अपने आराम क्षेत्र में रहना पसंद करते हैं और इससे ठहराव होता है।

— एंड्रियाशेचेर्ट

@AndreasScheinert नौकरी के लिए सही उपकरण का उपयोग करते हैं। ओओपी सभी परिदृश्यों के लिए काम नहीं करता है .... उनके आराम क्षेत्र के साथ कुछ नहीं करना है

— pqsk

Answer 5

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

आप यह तर्क दे सकते हैं कि यह केवल स्पष्ट रूप से यह बताते हुए बनाम विक्षेपण का मामला है, जो कि "नए प्रतिमान" जैसा कुछ नहीं है और वास्तव में सिर्फ अधिक सुविधाजनक है।