2010-07-15 11 views
11

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

धन्यवाद।

+3

मैंने कभी नहीं सुना है कि OOP बिल्कुल प्रक्रियात्मक नहीं है। आपको यह विचार कहां मिला? – p4bl0

+0

@ पी 4 बी 10: http: //en.wikipedia.org/wiki/Procedural_programming#Comparison_with_object-oriented_programming –

+1

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

उत्तर

10

ऐसा नहीं है कि ऑब्जेक्ट-ओरिएंट प्रोग्रामिंग "गैर-प्रक्रियात्मक" है; यह सिर्फ इतना है कि कोड हम कहते हैं "प्रक्रियात्मक" है नहीं है वस्तु उन्मुख (और कार्यात्मक नहीं है और शायद नहीं एक जोड़े अन्य)

यह इतना एक या तो या मामला है, लेकिन एक धीमी गति से gradiate नहीं है:

स्पेगेटी कोड -> संरचित कोड -> ऑब्जेक्ट उन्मुख कोड -> घटक कोड।

(अद्यतन: ऊपर चार्ट से निकाला गया "प्रक्रियात्मक", क्योंकि यह सही 3/इसके बारे में 4rds के सभी को संदर्भित करता है)

+1

वह स्पष्टीकरण मुझे समझ में आता है। लेकिन फिर मैंने हमेशा सोचा कि "ऑब्जेक्ट" कुछ पॉइंटर पॉइंट्स है और "ऑब्जेक्ट ओरिएंटेड" एक प्रतिमान है जो कार्यों या प्रक्रियाओं के बजाए उन वस्तुओं पर केंद्रित है। इसलिए ओओ में कार्य और प्रक्रियाओं ("विधियों") में एक अंतर्निहित पैरामीटर होता है (जिस वस्तु को वे कहते हैं)। –

+3

आपका "आरेख" यहां जैसा दिखता है कि किसी भी तरह से यह संकेत मिलता है कि प्रक्रिया कोड ऑब्जेक्ट-ओरिएंटेड कोड से कम है। वैसे भी: आप फंक्शनल कोड और जेनेरिक कोड कहां फेंकते हैं :)? –

+2

आप अधिक आयाम आवश्यकता होगी सही ढंग से इस संबंध (बहुत भयानक बाएं-दाएं राजनीतिक "स्पेक्ट्रम" की तरह) में कुछ भी चार्ट बनाने के लिए। मुझे लगता है कि यह अमूर्तता के सापेक्ष स्तर का एक सभ्य पर्याप्त स्केच है, हालांकि। मैंने व्यक्तिगत रूप से इसे "बेहतर/बदतर" के रूप में नहीं बताया। – Cogwheel

0

ओओपी सिर्फ encapsulation नहीं है।

पॉलिमॉर्फिज्म इसकी सबसे शक्तिशाली विशेषता है।

+0

धन्यवाद, मैंने पहले इसका उपयोग किया है ... हालांकि, यह कैसे गैर-प्रक्रियात्मक बनाता है। –

+2

जेम्स Curran आपको जवाब दे रहा है कि –

4

यह सिर्फ एक 'सम्मेलन' चीज है। जब लोग 'प्रक्रियात्मक' कहते हैं, तो यह निहित है कि यह ओओ नहीं है, और इसके विपरीत।

1

यह कभी भी प्रक्रियात्मक लेबल खो देता है। यह एक गलत धारणा है। ओओपी encapsulation और वस्तुओं से कहीं अधिक है। अधिक जानकारी के लिए here पर क्लिक करें।

3
विकी (अच्छी तरह से समझाया गया है) से

:

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

अधिक here पाया जा सकता है।

+0

"ऑब्जेक्ट उन्मुख प्रोग्रामिंग दोनों को एक साथ जोड़ता है ताकि एक" ऑब्जेक्ट "अपनी" डेटा "संरचना पर चल सके।" <- अब यह उच्च स्तर की आवाज बनाता है, फिर भी यह "सबसे महत्वपूर्ण भेद" लगता है? –

4

ओओपी प्रक्रियात्मक लेबल को ढीला नहीं करता है। Procedural programmingimperative programming है। ओओपी प्रक्रियात्मक प्रोग्रामिंग बढ़ाता है। सी ++ और उद्देश्य सी सी के ओओ एक्सटेंशन हैं। कार्यात्मक प्रोग्रामिंग आमतौर पर घोषणात्मक है - अनिवार्य के विपरीत।

7

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

+0

+1" अधिकांश ओओपी सिस्टम प्रक्रियात्मक भाषाओं के विस्तार पर आधारित हैं " –

5
;: (एक तरफ ध्यान दें के रूप में एक बहु प्रतिमान भाषा के रूप में, यह धारणात्मक OOP, जरूरी प्रोग्रामिंग, कार्यात्मक प्रोग्रामिंग के विभिन्न पहलुओं को अलग मदद करता है, जबकि उनमें से सभी उपलब्ध बनाने यही कारण है कि चीजें मैं एफ # बारे में पसंद से एक है।)

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

1

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

1

की 'उन्मुख' अपनी परिभाषा पर निर्भर करता है।

तो कोड के 51% हे-ओ है, यह अर्हता प्राप्त करता है?

2

http://en.wikipedia.org/wiki/Procedural_programming पर विकिपीडिया लेख ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग और प्रक्रियात्मक प्रोग्रामिंग के बीच मतभेद की एक सभ्य विवरण उपलब्ध कराती है, लेकिन कम, ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में वस्तुओं सहयोग के बजाय पर संचालित करने के लिए एक साथ प्रक्रियाओं stringing के बीच संदेशों के आदान के बारे में है ढीला डेटा संरचनाएं।

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

+0

बहुत अच्छी तरह से, धन्यवाद। –

संबंधित मुद्दे