वास्तव में प्रक्रियात्मक प्रोग्रामिंग क्या है? यह ओओपी से कितना अलग है? क्या यह कार्यात्मक प्रोग्रामिंग के समान है?


32

मैं जावा में एक बहुत ही ऑब्जेक्ट-ओरिएंटेड (OO) स्टाइल में प्रोग्रामिंग कर रहा हूं । OOP मेरे लिए बहुत सहज रूप से आता है, लेकिन मुझे अन्य प्रकार की प्रोग्रामिंग के बारे में बहुत कम जानकारी है।

वास्तव में प्रक्रियात्मक प्रोग्रामिंग क्या है ? यह ओओपी से कितना अलग है? क्या यह कार्यात्मक प्रोग्रामिंग के समान है ?

मुझे लगता है कि सभी प्रोग्रामिंग जो OO नहीं है, प्रक्रियात्मक है। लेकिन मुझे लगता है कि यह सच नहीं है।


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

2
प्रक्रियात्मक प्रोग्रामिंग कार्यात्मक प्रोग्रामिंग के समान नहीं है; यह वास्तव में अनिवार्य रूप से ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग, ऑब्जेक्ट्स और क्लासेस को घटाता है।
मेसन व्हीलर

1
इम्पीरियल OOP वास्तव में प्रक्रियात्मक प्रोग्रामिंग है, इसलिए यह वही है जो आप हर समय कर रहे हैं ...
Ingo

जवाबों:


68

इन शब्दों के लिए विकिपीडिया की अच्छी व्याख्या है। बावजूद, यहाँ सारांश है:


  • घोषणात्मक प्रोग्रामिंग अनिवार्य प्रोग्रामिंग के विपरीत है - यह निर्दिष्ट करता है कि कैसे (जैसे SQL, regexes) के बजाय क्या गणना करना है।

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

  • विशुद्ध रूप से कार्यात्मक प्रोग्रामिंग म्यूटेशन को पूरी तरह से अस्वीकार कर देता है (हालांकि लोकप्रिय धारणा के विपरीत अभी भी दुष्प्रभाव प्राप्त करने के लिए तंत्र है)।
  • कुल कार्यात्मक प्रोग्रामिंग इसके अतिरिक्त अपवादों और अनंत लूपिंग को मना करता है। (गणित में कुल फ़ंक्शन एक ऐसा फ़ंक्शन है जोइसके सभी इनपुट केलिए एक मान लौटाता है।)

उनके रिश्ते थोड़े जटिल हैं क्योंकि OOP एक बहुत ही भरा हुआ शब्द है। आप कार्यात्मक भाषाओं और प्रक्रियात्मक भाषाओं दोनों में वस्तुओं का उपयोग कर सकते हैं, लेकिन वे भाषाएँ जो स्वयं को OO के रूप में विज्ञापित करती हैं, प्रक्रियात्मक हैं। समस्या को और उलझाने के लिए:

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

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

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


3
"मनाही कूदता है" बल्कि सामान्य है; जिसमें शामिल है अगर / जबकि / आदि .. शायद "मनमानी कूदता मना"?
इज़काता 16

@ इज़कट अच्छा बिंदु, बदल गया।
डोभाल

1
वास्तव में विकिपीडिया प्रविष्टियों को जोड़ने के लायक हो सकता है।
हेयर स्टाइल

और यही कारण है कि इसे ऑब्जेक्ट "ओरिएंटेड" कहा जाता है और केवल ऑब्जेक्ट नहीं।
17

1
@OrangeDog कैसे एक सार डेटा प्रकार, जिसमें से है कि किसी भी तरह से अलग है भी डेटा और कार्यों कि उस पर कार्य कर सकते हैं की एक समझाया सेट को परिभाषित करता है? इसके अलावा, आपके पास अपरिवर्तनीय वस्तुएं हो सकती हैं, इसलिए उस स्थिति में, क्या स्थिति है ?
डोवाल

12

प्रक्रियात्मक प्रोग्रामिंग प्रोग्रामिंग के लिए एक दृष्टिकोण है जो कई अन्य भाषा डिजाइनों के लिए बिल्डिंग ब्लॉक के मूल में से एक है (कार्यात्मक एक नहीं है)।

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

BASIC प्रक्रियात्मक है।

जैसा कि दूसरों ने कहा है, यह क्रमबद्ध तरीके से कार्यक्रमों की संरचना के लिए एक तंत्र है।

  • पहले मैं एक्स करता हूं
  • दूसरा मैं y करता हूं
  • तीसरा मैं जेड करता हूं

इसे "प्रक्रियाओं" को परिभाषित करने के लिए एक तंत्र की आवश्यकता होती है - OO विधियों के समान नामित कोड के ब्लॉक, जो कई मापदंडों पर शून्य को स्वीकार कर सकते हैं, और वैकल्पिक रूप से एक मान लौटा सकते हैं (जिसे तब आमतौर पर एक फ़ंक्शन कहा जाता है - संभवतः कार्यात्मक भाषाओं के साथ आपके भ्रम की ओर जाता है )

प्रतिमान यह निर्धारित नहीं करता है कि आप जो काम करते हैं, वह होगा, या चीजों के तरीके के आसपास पारित किया जाएगा।

यह बस वर्णन करता है कि कार्यक्रम को प्रक्रियाओं (या कार्यों) की एक श्रृंखला के रूप में संरचित किया जाएगा जो क्रमबद्ध तरीके से काम करते हैं। डेटा को फिर प्रक्रियाओं से स्वतंत्र रूप से परिभाषित किया गया है।

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

इसके बारे में सोचने का एक तरीका डेटा स्कोप के संदर्भ में है।

एक प्रक्रियात्मक भाषा में स्कूपिंग काफी सरल है। एक चर किसी दिए गए प्रक्रिया के दायरे में हो सकता है (स्थानीय रूप से घोषित), ऊपर की चीज के स्तर तक (सामान्‍य रूप से घोषित), के बीच नेस्टेड स्कोप के साथ।

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

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


5

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

प्रक्रियात्मक प्रोग्रामिंग तब होती है जब आपके पास कंप्यूटर का एक मॉडल आपके सिर में एक मशीन के रूप में होता है, और आप सोच रहे हैं कि यह मेमोरी में डेटा को कैसे संशोधित कर रहा है। इसलिए पहले आप Aमान 3 पर सेट करते हैं, फिर आप 1 जोड़ते हैं और Aफिर से मेमोरी लोकेशन में स्टोर करते हैं (पिछले मूल्य को ओवरराइट करते हुए)।

कार्यात्मक प्रोग्रामिंग कह रही Aहै 3 है, और Bहै A + 1, और फिर कंप्यूटर को पता लगाने की गणना करने के लिए कैसे B। एक बार जब आप परिभाषित कर लेते हैं तो Aयह अपरिवर्तनीय (गैर-बदलते) होना चाहिए। फ़ंक्शनल आपको एक फ़र्स्ट-क्लास वैल्यू के रूप में फ़ंक्शन को पास करने की अनुमति भी देता है (एक फ़ंक्शन एक फ़ंक्शन को एक तर्क के रूप में ले सकता है)।

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


0

OOP प्रक्रियात्मक प्रोग्रामिंग के एक परिष्कृत रूप से कुछ भी नहीं है, जो फिर से अनिवार्य प्रोग्रामिंग के बड़े परिवार से संबंधित है। उस दावे का प्रमाण यह है कि कई C # / Java प्रोग्रामर "कुछ करने के लिए" होते हैं और जैसे तरीके पसंद करते हैं:

void doThisAndThat(....) { ... do something ... }

तो, एक प्रोग्राम जिसमें शून्य-विधियों का एक गुच्छा शामिल है (पूर्व में प्रक्रियाओं (sic!)) और कोड की तरह जाना जाता है ।

doThis();
if (state is that) doSomethingElse();
doThat();

सही प्रक्रियात्मक प्रोग्रामिंग है।


doThisAndThat (....) का तात्पर्य है कि एक विधि एक से अधिक कार्य करेगी जो सामान्य रूप से अच्छा व्यवहार नहीं है। जावा और सी # डेवलपर्स ज्यादातर एकल जिम्मेदारी सिद्धांत का पालन करते हैं। मुझे लगता है कि आपकी उपमा त्रुटिपूर्ण है। objectmentor.com/resources/articles/srp.pdf
16

@ जॉन मुझे पता है कि यह कोई अच्छा अभ्यास नहीं है। फिर भी एक आम। विशेष रूप से जावा डेवलपर्स के बीच, अगर कोई एसओ पर हर रोज देखता है, तो वह न्याय कर सकता है।
ingo

@ जॉन्क जावा और सी # डेवलपर्स ज्यादातर एकल जिम्मेदारी सिद्धांत का पालन करते हैं - होंठ सेवा?
ingo

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