सॉफ्टवेयर जटिलता को प्रबंधित करने के लिए क्या हमें वास्तव में OO भाषाओं की आवश्यकता है?

Question

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

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

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

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

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

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

Comments

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

— Marstato

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

— स्टैंडबैक

@RobbieDee क्या आपने वास्तव में मेरा प्रश्न पढ़ा है? यह ओओ को अधिक मौलिक स्तर पर समझने की कोशिश करने के बारे में है, मौसम पर सवाल उठाकर सॉफ्टवेयर जटिलता को ओओ के बिना प्रबंधित किया जा सकता है। मैं OO को कमतर आंकने की कोशिश नहीं कर रहा हूं, कुछ नया आविष्कार करने की कोशिश नहीं कर रहा हूं, मैं सिर्फ इसे बेहतर तरीके से समझने की कोशिश कर रहा हूं और अगर यह सवाल इतना ident स्व-स्पष्ट ’है तो इसे जॉर्ग का उत्कृष्ट जवाब क्यों मिला?

— स्टेकएक्सचेंज

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

— जेफ़ो

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

— डैनियल आर हिक्स

Answer 1

मुझे एक बहुत कम सिद्धांत जवाब के साथ कोशिश करते हैं :)

आप वास्तव में क्या पूछ रहे हैं: क्यों ऑब्जेक्ट ओरिएंटेशन (OO) के लिए समर्थन को सीधे भाषा में शामिल करें जब OO कोड को डिजाइन और लिखने के लिए प्रक्रियात्मक भाषाओं का उपयोग किया जा सकता है?

और इसका उत्तर है: ओओ को स्रोत कोड में कैसे व्यक्त किया जाता है, इसके लिए एक मानक होना चाहिए ताकि आप एक ही अमूर्त के लिए 22 विभिन्न कार्यान्वयनों के साथ समाप्त न हों।

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

मैं एक विशेष तरीके से नामकरण कार्यों के द्वारा समूहन कर सकता हूं, एक विशेष तरीके से MagicSlider_DoSomething ...नामित विशिष्ट फाइलों में विधियों को शामिल करके MagicSliderMethods.XXX, या मुझे एक ही काम करने के लिए कुछ अन्य विशेष तरीके मिल सकते हैं। अगर इसे करने के लिए भाषा में कोई मानक तरीका नहीं है, तो मैं इसे आपसे अलग कर दूंगा, और किसी और से अलग। यह साझाकरण कोड को और अधिक कठिन बनाता है।

हां, देर से प्रेषण - ओओ भाषाओं में आभासी तरीके - प्रक्रियात्मक भाषाओं में लागू किए जा सकते हैं, लेकिन इसे लागू करने के लिए कई अलग-अलग तरीके हैं। इस पर निर्भर करता है कि किसने कोड लिखा है, आप एक ही कार्यक्रम के अंदर OO के विभिन्न कार्यान्वयनों के साथ समाप्त हो जाएंगे।

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

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

Comments

क्लासिक उदाहरण: लुआ। यह मूल रूप से OO नहीं है, लेकिन इसे बनाया जा सकता है, लेकिन इसका मतलब है कि लगभग 5 अलग-अलग समान रूप से प्रसिद्ध OO लाइब्रेरी हैं जो पूरी तरह से इंटरऑपरेबल नहीं हैं।

— क्रोल्टन

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

— टिम बी

@nocomprende अमूर्त अमूर्तताएं लगभग शाब्दिक रूप से प्रोग्रामिंग भाषाएं हैं। डेढ़ दशक में दस हार्डवेयर पीढ़ियों की तरह कुछ के अंतर पर भी असेंबली भाषा सार।

— डेविड मोल्स

@DavidMoles मानकीकृत कपोल-कल्पना कर रहे हैं सचमुच क्या प्रोग्रामिंग भाषाओं कर रहे हैं। "सचमुच" का उपयोग करने के लिए एक सही अवसर बर्बाद मत करो!

— क्लेमेंट चेरलिन

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

— ग्राहम

Answer 2

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

उनमें से कोई भी OOP अवधारणाएं नहीं हैं। वे सभी OO से बाहर मौजूद हैं, OO से स्वतंत्र हैं और कई का आविष्कार OO से पहले भी हुआ था।

इसलिए, यदि आप सोचते हैं कि यही OO है, तो आपका निष्कर्ष सही है: आप उन सभी को प्रक्रियात्मक भाषाओं में कर सकते हैं, क्योंकि उनका OO से कोई लेना-देना नहीं है ।

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

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

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

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

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

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

आप जो वर्णन करते हैं वह OO है।

यह वास्तव में OO के बारे में सोचने का एक अच्छा तरीका है। वास्तव में, यह वास्तव में ओओ के मूल आविष्कारों के बारे में बहुत कुछ है। (एलन के एक कदम आगे बढ़ गया: उन्होंने नेटवर्क पर एक दूसरे को संदेश भेजने वाले बहुत से छोटे कंप्यूटरों की कल्पना की।) जिसे आप "प्रोग्राम" कहते हैं, उसे आमतौर पर "ऑब्जेक्ट" कहा जाता है और "कॉल" के बजाय हम आमतौर पर कहते हैं "एक संदेश भेजें। "।

ऑब्जेक्ट ओरिएंटेशन मैसेजिंग (उर्फ डायनामिक डिस्पैच ) के बारे में है। "ऑब्जेक्ट ओरिएंटेड" शब्द स्मॉलटाक के प्रमुख डिजाइनर डॉ। एलन के द्वारा गढ़ा गया था, और वह इसे इस तरह परिभाषित करते हैं :

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

चलो कि नीचे तोड़:

• मैसेजिंग ("वर्चुअल मेथड डिस्पैच", यदि आप स्मॉलटाकल से परिचित नहीं हैं)
• राज्य-प्रक्रिया होनी चाहिए
  • स्थानीय रूप से बनाए रखा
  • संरक्षित
  • छिपा हुआ
• सभी चीजों की चरम देर से बाध्यकारी

कार्यान्वयन-वार, मैसेजिंग एक लेट-बाउंड प्रक्रिया कॉल है, और यदि प्रक्रिया कॉल लेट-बाउंड हैं, तो आप डिज़ाइन समय पर यह नहीं जान सकते हैं कि आप क्या कॉल करने जा रहे हैं, इसलिए आप राज्य के ठोस प्रतिनिधित्व के बारे में कोई धारणा नहीं बना सकते हैं। इसलिए, वास्तव में यह संदेश देने के बारे में है, देर-बाध्यकारी संदेश का कार्यान्वयन है और इसके परिणामस्वरूप एनकैप्सुलेशन होता है।

बाद में उन्होंने स्पष्ट किया कि " बड़ा विचार 'संदेश' है , और पछतावा होने के कारण इसे" संदेश-उन्मुख "के बजाय" ऑब्जेक्ट-ओरिएंटेड "कहा जाता है, क्योंकि" ऑब्जेक्ट-ओरिएंटेड "शब्द का महत्व महत्वहीन चीजों (वस्तुओं) पर केंद्रित है ) और जो वास्तव में महत्वपूर्ण है (संदेश) से विचलित:

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

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

(बेशक, आज, ज्यादातर लोग वस्तुओं पर नहीं बल्कि कक्षाओं पर भी ध्यान केंद्रित करते हैं, जो और भी गलत है।)

संदेश OO के लिए मौलिक है, दोनों रूपक और एक तंत्र के रूप में।

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

"मैसेजिंग" के लिए एक अधिक "आधुनिक" शब्द "डायनेमिक विधि प्रेषण" या "वर्चुअल मेथड कॉल" है, लेकिन यह रूपक खो देता है और तंत्र पर ध्यान केंद्रित करता है।

इसलिए, एलन के की परिभाषा को देखने के दो तरीके हैं: यदि आप इसे अपने दम पर खड़े देखते हैं, तो आप देख सकते हैं कि संदेश मूल रूप से एक देर से बाध्य प्रक्रिया कॉल है और देर-बाइंडिंग का तात्पर्य है, ताकि हम यह निष्कर्ष निकाल सकें कि # 1 और # 2 वास्तव में बेमानी हैं, और OO सभी देर से बाध्यकारी है।

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

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

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

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

प्रकार और प्रोग्रामिंग भाषाओं में बेंजामिन पियर्स का तर्क है कि ऑब्जेक्ट-ओरिएंटेशन की परिभाषित विशेषता ओपन रिकर्सन है ।

तो: एलन Kay के अनुसार, OO मैसेजिंग के बारे में है। विलियम कुक के अनुसार, ओओ गतिशील पद्धति प्रेषण के बारे में है (जो वास्तव में एक ही बात है)। बेंजामिन पियर्स के अनुसार, OO सभी ओपन रिकर्सियन के बारे में है, जिसका मूल अर्थ है कि स्व-संदर्भों को गतिशील रूप से हल किया जाता है (या कम से कम यह सोचने का एक तरीका है), या, दूसरे शब्दों में, संदेश।

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

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

Comments

+100 - हम चीजों पर निहित दोष लगाते हैं क्योंकि उनका अनुचित उपयोग किया जा रहा है।

— जेफ़ो

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

— मेसन व्हीलर

@steakexchange No. "OO का सार," जो चीज इसे वास्तव में विशिष्ट बनाती है, वह है आभासी तरीकों वाली वस्तुएं। कोई कारण नहीं है कि कोई भी व्यक्ति Smalltalk का उपयोग नहीं करता है: संदेश-पासिंग सिस्टम व्यक्तिगत-कंप्यूटर पैमानों पर बहुत खराब काम करता है। हर बार कुछ सुविचारित लेकिन भोले भाषा के डिजाइनर स्मालटाक सिद्धांतों को फिर से लागू करने की कोशिश करते हैं, यह विफल हो जाता है। (सबसे हालिया उदाहरण ऑब्जेक्टिव-सी होगा, जिसका उपयोग किसी ने भी नहीं किया होगा यदि स्टीव जॉब्स ने इसे पूरे आईओएस समुदाय के गले नहीं उतारा है। यह एप्पल इकोसिस्टम के बाहर कभी कोई कर्षण नहीं पाया गया है, और इसका एक कारण है। )

— मेसन व्हीलर

@MasonWheeler क्या आप एक जवाब में अपनी टिप्पणी पर विस्तार से बता सकते हैं क्योंकि आपके पास जोर्ग के कहे जाने वाले विचारों के विपरीत है?

— स्टेकएक्सचेंज

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

— टी। सर

Answer 3

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

जब आप कहते हैं, "बहुत आसानी से" आप बहुत बोल्ड बयान दे रहे हैं। जिस तरह से मैंने इसे पढ़ा है वह यह है: "मैं कठिनाई नहीं देखता, इसलिए यह बहुत बड़ी नहीं होनी चाहिए।" जब इस तरह से काम किया जाता है, तो यह स्पष्ट हो जाता है कि आप पूछ रहे हैं कि "हमें OO की आवश्यकता क्यों है", आप पूछ रहे हैं "कि अन्य प्रोग्रामिंग प्रतिमानों के कारण कठिनाइयों का सामना क्यों नहीं करना पड़ा, जिससे OO के आविष्कार का नेतृत्व तुरंत मेरे लिए स्पष्ट हो गया? "

उस प्रश्न का उत्तर यह है कि इनमें से कई कठिनाइयाँ उन कार्यक्रमों में मौजूद नहीं हैं, जिन पर आप काम कर रहे हैं। आपको 40-वर्षीय पुराने स्पेगेटी कोड को अपडेट करने के लिए नहीं कहा जा रहा है। आप एक ऑपरेटिंग सिस्टम के लिए एक नया डिस्प्ले मैनेजर लिखने का प्रयास नहीं कर रहे हैं। आप बहु-वितरित वितरण अनुप्रयोगों को डीबग नहीं कर रहे हैं।

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

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

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

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

एक कुशल, अनुशासित पर्याप्त प्रोग्रामर वास्तव में C, या असेंबली में एक कार्यशील उच्च-जटिलता प्रणाली बना सकता है। लेकिन हम सभी लिनुस टोरवाल्ड्स नहीं हैं। न ही हमें उपयोगी सॉफ्टवेयर बनाने के लिए होना चाहिए।

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

इसलिए मैं आपके प्रश्न को चारों ओर घुमा दूंगा, और आपसे पूछूंगा कि यदि भाषाएं एन्कैप्सुलेशन और बहुरूपता जैसी सुविधाजनक सुविधाएँ प्रदान करती हैं, तो हमें उनका उपयोग क्यों नहीं करना चाहिए?

Comments

इसलिए मूल रूप से ओओ को एक प्रक्रियात्मक भाषा के साथ करना संभव है, लेकिन यह मानकीकृत ओओ भाषा का उपयोग करते हुए मैन्युअल रूप से चीजें कर रहा है और सरल करता है।

— स्टेकएक्सचेंज

@steakexchange बहुत सुंदर बिल्कुल।

— टिम बी

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

— उक्को

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

— क्लेमेंट चेरलिन

यह मेरे लिए दिलचस्प है कि आप जिन उदाहरणों के लिए OO से लाभान्वित होंगे, वे उदाहरण अक्सर OO भाषाओं में नहीं लिखे जाते हैं। 40 साल पुरानी स्पेगेटी को C, COBOL, FORTRAN या REXX में लिखे जाने की संभावना है। प्रदर्शन प्रबंधक को संभवतः C (OO-ish सम्मेलनों के साथ) में लिखा गया है, और कई सफल वितरित मल्टीथ्रेडेड सिस्टम Erlang, Go या C. में लिखे गए हैं

— James_pic

Answer 4

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

सबसे पहले, यह ध्यान देने योग्य है कि ओओपी की कोई एक परिभाषा नहीं है, इसलिए ऐसे लोग भी हो सकते हैं जो ओओपी की विशेषता के साथ असहमत हैं।

दूसरे, यह याद रखना महत्वपूर्ण है कि ओओपी डिजाइन के पारंपरिक मॉडल से प्रेरित था, इसलिए कार डिजाइन की समानता कोई संयोग नहीं है।

हालाँकि, आपके द्वारा कहे गए तरीकों की तुलना में यहाँ OOP कुछ अधिक है।

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

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

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

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

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

Comments

अच्छा उत्तर! एक हिस्सा जिससे मैं सहमत नहीं हूं: आप जिस अंतर के बारे में ड्राइंग कर रहे हैं, वह मान्य नहीं है। एनकैप्सुलेशन का हमेशा मतलब होता है "इस इंटरफ़ेस से परे पहुँचना" - यह OOP और गैर-OOP सेटिंग के लिए एक जैसा है। तो यह हिस्सा वास्तव में ऐसा कुछ नहीं है जो OOP के लिए अद्वितीय हो।

— डीडब्ल्यू

@ मैंने यह स्पष्ट करने की कोशिश की है, यह कहते हुए कि यह ओओपी के लिए अद्वितीय नहीं है, लेकिन यह एनकैप्सुलेशन और अमूर्त के बीच का अंतर है। प्रतिक्रिया के लिए धन्यवाद!

— जेमाइट

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

— डीडब्ल्यू

वंशानुक्रम एक सामान्य विशेषता है, लेकिन कई महत्वपूर्ण OO भाषाओं में इसका अभाव है।

— ब्रैड सजोनी

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

— डेविड

Answer 5

सॉफ्टवेयर जटिलता को प्रबंधित करने के लिए क्या हमें वास्तव में OO भाषाओं की आवश्यकता है?

यह शब्द के अर्थ पर निर्भर करता है, "आवश्यकता है।"

यदि "आवश्यकता" का अर्थ है आवश्यकता है, नहीं, हमें इसकी आवश्यकता नहीं है।

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

बड़ी तस्वीर

OO भाषाएँ डेटा के लिए कार्यक्षमता को बांधती हैं।

आप इस बाइंडिंग से बच सकते हैं और ऐसे फ़ंक्शन लिख सकते हैं जो डेटा मानों के आसपास से गुजरते हैं।

लेकिन तब आप संभवतः डेटा के नक्षत्रों के साथ जुड़ जाएंगे, जो एक साथ चलते हैं, और आप डेटा के ट्यूपल्स, रिकॉर्ड्स या शब्दकोशों के आसपास से गुजरना शुरू कर देंगे।

और वास्तव में, यह सभी विधि कॉल हैं: डेटा के बाध्य सेट पर आंशिक कार्य।

फीचर से फीचर

OOP की विशेषताएं:

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

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

संदर्भ

ओओपी के बहुत सारे आलोचक हैं ।

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

निष्कर्ष

हमें "OOP" की आवश्यकता नहीं है। लेकिन कुछ मामलों में उपयोगकर्ता OOP चाहता है ।

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

Answer 6

मैं संक्षिप्त होने की कोशिश करूंगा।

OO का मुख्य सिद्धांत एकल संगठनात्मक इकाई (एक वस्तु) में डेटा और व्यवहार का संयोजन है।

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

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

तो, हाँ, OO एक बड़ी बात है। और नहीं, यह सिर्फ एक फैंसी नाम के साथ पुराने सामान का एक गुच्छा नहीं है।

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

Answer 7

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

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

मुझे लगता है कि जटिलता के प्रबंधन के लिए उपयोग किए जाने वाले सभी सिद्धांतों को प्रक्रियात्मक प्रोग्रामिंग भाषाओं द्वारा महसूस किया जा सकता है।

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

Answer 8

कुछ अन्य जवाबों का उल्लेख नहीं किया गया है: राज्य।

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

मुझे लगता है कि हम राज्य से संबंधित जटिलता के बारे में बात कर रहे हैं।

इनकैप्सुलेशन के पीछे दो मुख्य विचार हैं । उनमें से एक, कार्यान्वयन विवरणों का छिपाना , अन्य उत्तरों में बहुत अच्छी तरह से कवर किया गया है। लेकिन दूसरा अपनी भाग-दौड़ की स्थिति को छिपा रहा है । हम वस्तुओं के आंतरिक डेटा के साथ आसपास नहीं टकराते हैं; यदि आप अवधारणा पर कार्यान्वयन विवरण पसंद करते हैं तो हम संदेश पास करते हैं (या कॉल के तरीके को पसंद करते हैं जैसा कि Jörg Mittag ने बताया है)। क्यों?

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

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

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

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

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

Answer 9

सॉफ्टवेयर जटिलता को प्रबंधित करने के लिए क्या हमें वास्तव में OO भाषाओं की आवश्यकता है?

नहीं, लेकिन वे कई स्थितियों में मदद कर सकते हैं।

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

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

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

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

Answer 10

जैसा कि कोई है जो पूरी तरह से सी में लिखे गए एक बहुत बड़े प्रोजेक्ट में शामिल है, मैं निश्चित रूप से कह सकता हूं कि जवाब एक स्पष्ट "नहीं" है।

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

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

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

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

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

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

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

Comments

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

— विंसेंट सवार्ड

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

— मछली मारना

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

— जूल्स

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

— जूल्स

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

— जूल्स

Answer 11

ऑब्जेक्ट-ओरिएंटेड विधियों सहित प्रोग्रामिंग प्रतिमानों को शुरू करने का कारण, अधिक परिष्कृत और शक्तिशाली कार्यक्रम बनाना आसान है। बाइट पत्रिका के अगस्त 1981 के अंक में, डैनियल इंगल्स , स्मॉलटाक के प्रमुख रचनाकारों में से एक, ने निम्नलिखित क्षमताओं को शामिल करते हुए "ऑब्जेक्ट ओरिएंटेड" को परिभाषित किया:

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

ये सिद्धांत थे इनगॉल की पहचान स्मॉलटॉक -80 के लिए ड्राइविंग डिज़ाइन विचार के रूप में की गई थी जो कि ज़ेरॉक्स पार्स रिसर्च द्वारा विकसित किया गया था। उपर्युक्त पत्रिका लेख में आप इन सिद्धांतों में से प्रत्येक का एक विस्तृत विवरण पढ़ सकते हैं और वे Ingalls के अनुसार वस्तु-उन्मुख प्रतिमान में कैसे योगदान करते हैं।

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

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

Comments

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

Answer 12

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

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

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

Answer 13

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

उद्देश्य है - सॉफ्टवेयर जटिलता प्रबंधित करें । उद्देश्य "ओओ भाषा का उपयोग नहीं" है।

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

---

वास्तविक विश्व संस्थाओं के संदर्भ में कोडिंग बस स्पष्ट और सही तरीका है जब हम वास्तविक विश्व संस्थाओं के बारे में कोडिंग करते हैं ।

---

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

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

इसलिए आप कोड लिख सकते हैं जो एन्क्रिप्टेड और अच्छी तरह से दोनों समझाया गया है क्योंकि ये दोनों अलग-अलग अवधारणाएं हैं।

एनकैप्सुलेशन वास्तविकता के करीब होने के कारण जटिलता को प्रबंधित करने में मदद करता है।

इसलिए, ऑब्जेक्ट्स में प्रोग्राम करें क्योंकि, आपके लिए कोड करना आसान है और यह आपके लिए और बाकी सभी को समझने में तेज़ है।

Answer 14

याद रखने वाली एक बात यह है:
ओओपी भाषा सुविधाओं के बारे में नहीं है; यह आपके कोड को तैयार करने के तरीके के बारे में है ।

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

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

तो, नहीं, हमें OOP करने के लिए OO भाषाओं की आवश्यकता नहीं है । यह सिर्फ इतना है कि OOP एक सभ्य OO भाषा के साथ करना इतना आसान है।

Answer 15

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग सिर्फ मॉड्यूल + एनकैप्सुलेशन से अधिक है। जैसा कि आप कहते हैं, गैर-ऑब्जेक्ट-ओरिएंटेड (प्रक्रियात्मक) भाषा में मॉड्यूल + एनकैप्सुलेशन का उपयोग करना संभव है। OOP में केवल इससे अधिक शामिल हैं: इसमें ऑब्जेक्ट और विधियाँ शामिल हैं। तो, नहीं, यह OOP पर कब्जा नहीं करता है। देखें, जैसे, https://en.wikipedia.org/wiki/Object-oriented_programming या OOP के लिए एक अच्छी पाठ्यपुस्तक का परिचय।

Comments

जवाब के लिए धन्यवाद। क्या आप एक की सिफारिश कर सकते हैं?

— स्टेकएक्सचेंज

Answer 16

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

आइए 100 वर्गों की एक प्रणाली की कल्पना करें, प्रत्येक के बारे में 20 ऑपरेशन जो उन पर किए जा सकते हैं; यह 2,000 कार्य है। हालांकि, उनमें से, शायद केवल 500 ही 'सेव' और 'डिलीट' जैसे पूर्ण संचालन हैं, जबकि 1500 आंतरिक कार्य हैं जो थोड़ा सा रखरखाव करते हैं, या कुछ उपयोगिता भूमिका रखते हैं। विचार करें;

// intentionally in a non-specific language!

setName(person, name) {
    nameParts = splitPersonName(name);
    person.firstName = nameParts[0];
    person.lastName = nameParts[1];
    person.modified = true;
}

splitPersonName(name) {
    var result = [];
    result.add(name.substring(0, name.indexOf(" ")));
    result.add(name.substring(name.indexOf(" ") + 1));
    return result;
}

तो SetNameएक फ़ंक्शन एक व्यक्ति को एक व्यक्ति को करना चाहिए , लेकिन SplitPersonNameएक उपयोगिता फ़ंक्शन है जो व्यक्ति द्वारा उपयोग किया जाता है ।

सीधे प्रक्रियात्मक प्रोग्रामिंग इन दो कार्यों के बीच कोई अंतर नहीं करता है। इसका मतलब है कि आपके ध्यान के लिए आपके 2,000 कार्यात्मक सभी vie हैं। हालाँकि, अगर हम इन कार्यों को 'उन सभी के लिए उपलब्ध हैं, जिनके पास एक व्यक्ति रिकॉर्ड है' और 'व्यक्ति रिकॉर्ड के अंदर केवल एक उपयोगिता फ़ंक्शन के रूप में उपयोग किया जाता है' को चिह्नित कर सकता है, तो हमारा ध्यान अब 500 'हर किसी के लिए उपलब्ध है, और 15' उपयोगिता ' आपके द्वारा संपादित किए जा रहे वर्ग के लिए कार्य।

यही तो publicऔर privateकरना है;

public class Person {
    public void setName(...) {...}
    private string[] splitPersonName(...) { ...}
}

Comments

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

— स्टेकएक्सचेंज

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

— user62575

@steakexchange ध्यान दें कि OOP एक समय विकसित किया गया था जहाँ कई प्रक्रियात्मक भाषाओं में उस तरह के मॉड्यूल नहीं थे । कुछ ऐसी भाषाओं को प्रक्रियात्मक भी नहीं कहेंगे। वास्तव में, ऐसा कुछ भी नहीं है जो कहता है कि एक प्रक्रियात्मक भाषा OO या इसके विपरीत नहीं होनी चाहिए। लेबल से सावधान रहें - वे आसानी से आपको भ्रमित कर सकते हैं। यदि आपकी प्रक्रियात्मक भाषा सार्वजनिक और निजी क्षेत्रों और प्रक्रियाओं वाले मॉड्यूल का समर्थन करती है, तो आपके लिए अच्छा :) "पारंपरिक प्रक्रियात्मक" और "ओओपी" के बीच मुख्य अंतर यह है कि कॉल प्रेषण ओओपी में अधिक लचीला है - वास्तव में, सख्त ओओपी में, आप कभी नहीं पता कि आप किस कोड को कॉल करते हैं।

— लुअन

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

— लुअन

C के पास प्रभावी रूप से ये चीजें हैं। इसमें इंटरफेस (.h फाइलें) के साथ मॉड्यूल (.c फाइलें) हैं और इसमें सार्वजनिक (बाहरी) और गैर-सार्वजनिक (बाहरी) तरीके (कार्य) हो सकते हैं। तुम भी गरीब आदमी के बहुरूपता समारोह संकेत की सरणियों के साथ हो सकता है, मैं नहीं कह रहा हूँ OO सी में आसान है (या शायद, समझदार), लेकिन encapsulation बहुत आसान है,

— निक Keighley