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


12

मैं प्रोग्रामिंग के लिए बहुत नया हूं और विभिन्न स्रोतों से विभिन्न सम्मेलनों को पढ़ने / सुनने से थोड़ा भ्रमित हूं:

क्या ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में 4 या 5 अवधारणाएँ हैं?

एक नवागंतुक के रूप में, मैं समझता हूं कि ये 5 अवधारणाएं हैं:

  • मतिहीनता
  • विरासत
  • encapsulation
  • बहुरूपता
  • प्रतिरूपकता

तो कैसे मैं एक और अधिक "सख्त" परिभाषा नहीं ढूंढता हूं और वहां इन अवधारणाओं की कई व्यवस्थाएं लगती हैं?


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

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

9
एक और बात यह है कि OOP समय के साथ बदल रहा है। प्रारंभिक सी ++ दिनों में बहुत अधिक ध्यान केंद्रित (मुझे पता है कि ओओपी उससे आगे जाता है) वंशानुक्रम और बहुरूपतावाद पर था। ध्यान केंद्रित Abstraction और Encapsulation पर कहीं अधिक है।
बेंट

3
OO की परिभाषा में सटीकता की कमी के बारे में कुछ दिलचस्प चर्चा यहाँ पाई जा सकती है: c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
मिशेल हेनरी

जवाबों:


26

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

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


12

क्या ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में 5 या 4 घटक हैं?

जैसा कि दूसरों ने उल्लेख किया है, "ओओ" के पास वास्तव में कोई घटक नहीं है , क्योंकि यह समस्याओं के मॉडलिंग समाधान के बारे में सोचने का एक तरीका है और टूलकिट नहीं है और न ही स्पष्ट रूप से परिभाषित प्रक्रियाओं का एक सेट है।

एक नवागंतुक के रूप में, मैं समझता हूं कि ये 5 घटक हैं:

अमूर्तता, विरासत, इनकैप्सुलेशन, बहुरूपता और प्रतिरूपकता?

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

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

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

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

उदाहरण के लिए, क्लासिक उदाहरण अक्सर इस तरह के रूप में संस्थाओं को देखें Dog, Cat, Elephant, Seagull, Shark, आदि अक्सर इस तरह के उदाहरणों को देखते हैं और तुरंत लगता है कि "OO" करने के लिए नए चेहरे "ओह, मैं एक आधार कहा जाता इकाई की जरूरत है Animal" , और वे भी अन्य के साथ खत्म हो सकता है मध्यवर्ती संस्थाओं जैसे कि Mammalऔर Amphibianएक स्वच्छ विरासत उत्तराधिकार में, हर एक में अलग-अलग विशेषताओं के साथ।

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

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

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


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

10

"ऑब्जेक्ट-ओरिएंटेशन" शब्द डॉ। एलन काय द्वारा गढ़ा गया था, इसलिए वह इसका अर्थ क्या है, इस पर आधिकारिक स्रोत है, और वह इसे इस प्रकार परिभाषित करता है :

ओओपी टू का मतलब केवल मैसेजिंग, लोकल रिटेंशन और प्रोटेक्शन और स्टेट-प्रोसेस को छुपाना, और सभी चीजों की एक्सट्रीम लेट-बाइंडिंग है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


1
@DavidArno आपकी टिप्पणी रचनात्मक नहीं है। एलन के खुद का दावा है कि उन्होंने इस अवधारणा के लिए "ऑब्जेक्ट" शब्द गढ़ा था (हालांकि, मुझे लगता है, अवधारणा ही नहीं)। यदि आप विषय पर एक प्रसिद्ध प्राधिकरण का विरोध करने जा रहे हैं, तो कम से कम अधिक रचनात्मक टिप्पणी लिखें।
एंड्रेस एफ।

1
@DavidArno इसके अलावा, क्या आपका डाउनवोट है? इसलिए किसी ने ओएचओपी के अर्थ पर जाने-माने विशेषज्ञों से अलग-अलग विचारों की एक व्यापक सूची लिखने का समय लिया, और आपने इसे अस्वीकार कर दिया क्योंकि आप एक वाक्य से असहमत हैं? Oookay।
एंड्रेस एफ।

2
@AndresF। इस उत्तर को "इस प्रकार से देखा जा सकता है कि हालांकि, एलन के, और बाकी सभी के दो स्कूल हैं। क्योंकि पूर्व के शब्द का अर्थ है कि वह स्वतः ही सही है और जो भी उससे असहमत है वह गलत है"। यह अथॉरिटी फॉरमेसी आंसर की अपील है। इस प्रकार डाउनवोट।
डेविड अर्नो

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

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

3

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

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

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

मॉड्यूल "बड़े में प्रोग्रामिंग" का समर्थन करने के लिए डिज़ाइन किए गए हैं ... जहां एक व्यक्ति को पूरी तरह से समझने के लिए आपका कोड-आधार बहुत बड़ा हो जाता है। और आपको अपने कोड को संशोधित करने के लिए प्रोग्रामिंग भाषा में मॉड्यूल की आवश्यकता नहीं है


मैं अन्य 4 विशेषता के बारे में बहस में नहीं पड़ रहा हूं, और क्या (उदाहरण के लिए) "वंशानुक्रम" के कौन से मॉडल शुद्ध OO हैं। इसके अलावा, जबकि एलन के को ओओ प्रोग्रामिंग का आविष्कार करने का श्रेय दिया जाता है, लेकिन इसका मतलब यह नहीं है कि ओओ / और ओओपीएल की उनकी परिभाषा में प्रधानता है। जाहिर है इस मामले में ऐसा नहीं है। वह एक आधिकारिक स्रोत है, लेकिन अन्य स्रोत हैं जो OO & OOPLs के लिए अन्य परिभाषा देते हैं कि (व्यवहार में) अधिक से अधिक वजन।


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

+1 @AndresF टिप्पणी। वास्तव में, "संरचित प्रोग्रामिंग" और "स्टेप-वाइज रिफाइनमेंट" (सोचने की संरचना के लिए एक तकनीक) "बढ़ती जटिलता के क्रूसिबल से निकलती है जिसके परिणामस्वरूप और भी बदतर सॉफ़्टवेयर"। अगर यह COBOL से पहले होता कि भाषा की ऐसी नकारात्मक प्रतिष्ठा IMHO नहीं होती। और मैं ओओ को व्यावहारिक रूप से केवल उच्च-क्रम संरचना के रूप में देखता हूं। और मेरा मतलब है कि अंतर्निहित संरचना ओ / आउट सबसे खराब COBOL से बेहतर नहीं है।
राडारबॉब
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.