OOP बनाम कार्यात्मक प्रोग्रामिंग बनाम प्रक्रियात्मक [बंद]


237

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

वास्तुकला के उदाहरणों की सराहना की!


यह पूर्ण उत्तर नहीं है, लेकिन मैं थोड़ा लिखता हूं कि "कार्यात्मक" "OO" शैली को कैसे प्रभावित करता है / (F # के संदर्भ में) यहां: lorgonblog.spaces.live.com/blog/cns! -701673171766D310 -511! प्रविष्टि
ब्रायन

आप इसे पढ़ने पर विचार कर सकते हैं ! कब कौन से चीजो का उपयोग करना है, इसके कई उदाहरण हैं, मुख्य अंतर क्या है, पेशेवरों / विपक्ष आदि
निकिता इग्नाटोव


1
इन्हें भी देखें: stackoverflow.com/questions/1530868
dreftymac

अंकल बॉब ने इस बारे में ट्वीट किया है। और यहां भी ।
jaco0646

जवाबों:


129

वे सभी अपने तरीके से अच्छे हैं - वे एक ही समस्याओं के लिए अलग-अलग दृष्टिकोण रखते हैं।

विशुद्ध रूप से प्रक्रियात्मक शैली में, डेटा उस पर काम करने वाले कार्यों से अत्यधिक विघटित हो जाता है।

ऑब्जेक्ट ओरिएंटेड स्टाइल में, डेटा अपने साथ फंक्शन्स का संग्रह ले जाता है।

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

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

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

जिस विकल्प का आप उपयोग करते हैं, वह बस वही है जो आपकी परियोजना के लिए अधिक मायने रखता है और आपकी भाषा का समर्थन करता है।


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

1
@TechZilla: मैं मानता हूं कि मेरा शब्दांकन खराब था, लेकिन मेरा मतलब यह था कि वास्तव में उन विशेषताओं की एक सूची नहीं है, जिन्हें आप इंगित कर सकते हैं और कह सकते हैं कि भाषा X, वाई की योग्यता के बिना बेहतर है कि भाषा X एल्गोरिथ्म यू और भाषा लिखने के लिए बेहतर है एल्गोरिथ्म V लिखने के लिए Y बेहतर हो सकता है, जबकि दोनों को आसानी से किसी भी भाषा में लागू किया जा सकता है।
ग्रेफेड 15

2
प्रक्रियात्मक और कार्यात्मक के बीच का अंतर मेरे लिए स्पष्ट नहीं है। मैं कॉलेज में स्कीम / रैकेट सीख रहा हूँ, लेकिन मैं वास्तव में इसके और प्रक्रियात्मक C या PHP के बीच बड़ा अंतर नहीं देख सकता, क्या आप कुछ उदाहरण दे सकते हैं?
लियोनेल

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

2
@ टैस्ट्रो: जब एक प्रतिमान दूसरे की तुलना में अधिक समझ में आता है। वास्तव में यह सब है। कभी-कभी यह आपके कोड को फ़ंक्शन की संरचना के रूप में मॉडल करने के लिए अधिक समझ में आता है, और कभी-कभी यह आपके डेटा को ऑब्जेक्ट के रूप में मॉडल करने के लिए अधिक समझ में आता है। एल्गोरिदम और डेटा संरचनाओं को व्यक्त करने के कई तरीके हैं। OOP और कार्यात्मक उन चीजों में से दो होते हैं।
ग्रेफेड

25

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

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

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

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


5
पायथन, रूबी, ... के पास C या LISP जैसी "मानक" लाइब्रेरी नहीं हैं, क्योंकि वे एकल कार्यान्वयन भाषा हैं। पायथन वही है जो गुइडो कहता है, कोई मानक नहीं है। कोई विशेष सी या एलआईएसपी (या जो भी) आजकल कार्यान्वयन मानक लोगों से परे पुस्तकालयों के एक बड़े सेट के साथ आता है।
डैन एंड्रीटा

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

1
ircmaxell के संबंधित शेख़ी: blog.ircmaxell.com/2012/07/oop-vs-procedural-code.html
rinogo

20

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

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

जबकि सी जैसी एक प्रक्रियात्मक भाषा में, आप फ़ंक्शन के पास का एकमात्र तरीका फ़ंक्शन पॉइंटर्स का उपयोग करके कर सकते हैं, और यह कि अकेले कई शक्तिशाली कार्यों को सक्षम नहीं करता है।

अजगर में, एक फ़ंक्शन प्रथम श्रेणी का नागरिक होता है, लेकिन इसमें मनमाने ढंग से संख्याएँ हो सकती हैं। तो आपके पास एक फ़ंक्शन हो सकता है जिसमें प्रक्रियात्मक कोड होता है, लेकिन आप इसे कार्यात्मक भाषाओं की तरह पास कर सकते हैं।

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

पायथन में, आपके पास यह प्रतिबंध नहीं है।


मेरा मानना ​​है कि आपका मतलब "इन प्रतिमानों का परस्पर अनन्य होना नहीं है"। उनमें से 3 हैं ओर्थोगोनल कि आदर्श आप एक, 2 या उनमें से 3 एक भी कार्यक्रम में इस्तेमाल कर सकते हैं में (अपनी भाषा यह अनुमति दे)।
जो पिनेडा

हाँ, मुझे लगता है कि पारस्परिक रूप से अनन्य उस के लिए एक बेहतर शब्द है! धन्यवाद
Hasen

14

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

मुझे नहीं लगता कि यह न तो भाषा का कोई सवाल है। आप लगभग किसी भी लोकप्रिय भाषा में कार्यात्मक, प्रक्रियात्मक या वस्तु-उन्मुख लिख सकते हैं, हालांकि यह कुछ में कुछ अतिरिक्त प्रयास हो सकता है।


17
"वस्तु = जीयूआई विजेट" गलत धारणा को समाप्त करने के लिए उकसाया गया, लेकिन मैं मना करूंगा। OOP केवल अमूर्त अवधारणाओं का प्रतिनिधित्व करने के लिए काम करता है, जैसे "UserAccount" या "PendingSale", जैसा कि "विंडो" और "बटन" जैसे दृश्य इंटरफ़ेस तत्वों के लिए।
डेव शेरोहमान

5
मैंने लिखा कि एक खिड़की एक वस्तु हो सकती है। आप यह निष्कर्ष कैसे निकालते हैं कि प्रत्येक वस्तु वहां से एक खिड़की है? यह सिर्फ एक उदाहरण था। बेशक OOP का उपयोग केवल अमूर्त संस्थाओं और उनके संबंधों को मॉडल करने के लिए किया जा सकता है। वैसे भी, नहीं downvoting के लिए धन्यवाद। मेरे पास वैसे भी कई बिंदु नहीं हैं: D
panschk

6
-1। OOP का GUI से कोई लेना-देना नहीं है। आदर्श रूप से, गिनी डिजाइन के लिए सबसे अच्छी विधि एक बाहरी पाठ फ़ाइल (जैसे HTML) का उपयोग कर रही है। जबकि स्ट्रिंग-प्रोसेसिंग जैसी चीजें वास्तव में वस्तुओं के साथ बहुत बेहतर होती हैं। (सी में तार के बारे में सोचो) !!
hasen

1
मुझे नहीं पता, शायद मैं इसे महसूस करने के लिए वस्तुओं के साथ प्रोग्रामिंग करने के लिए उपयोग कर रहा हूं। लेकिन जब आप ऑब्जेक्ट का उपयोग किए बिना TextBox Y का मूल्य बदल दिया गया है, तो आप TextBox X में मान को बदलने जैसे कुछ इंटरेक्टिव सामान कैसे करेंगे? ठीक है, आप बस सब कुछ के लिए वैश्विक
संस्करण का

1
स्ट्रिंग प्रसंस्करण अजीब ढंग से पर्ल में किया जाता है (जावा, सी ++ या सी # की तुलना में 100x बेहतर) फिर भी भाषा की स्ट्रिंग कार्यक्षमता बिल्कुल ऑब्जेक्ट ओरिएंटेड नहीं है। सी की स्ट्रिंग हैंडलिंग भयानक थी, लेकिन तब सी केवल प्रक्रियात्मक भाषा नहीं है (न ही सबसे अच्छी)।
जो पिनेडा

6

आपके प्रश्न का उत्तर देने के लिए, हमें दो तत्वों की आवश्यकता है:

  1. विभिन्न वास्तुकला शैलियों / पैटर्न की विशेषताओं की समझ।
  2. विभिन्न प्रोग्रामिंग प्रतिमानों की विशेषताओं को समझना।

सॉफ्टवेयर आर्किटेक्चर स्टाइल / पैटर्न की एक सूची विकिपीडिया पर सॉफ्टवेयर आर्किटेक्चर लेख पर दिखाई गई है । और आप उन पर आसानी से वेब पर शोध कर सकते हैं।

संक्षेप में और सामान्य तौर पर, प्रक्रियात्मक एक मॉडल के लिए अच्छा है जो एक प्रक्रिया का पालन करता है, ओओपी डिजाइन के लिए अच्छा है, और कार्यात्मक उच्च स्तरीय प्रोग्रामिंग के लिए अच्छा है।

मुझे लगता है कि आपको प्रत्येक प्रतिमान पर इतिहास पढ़ने की कोशिश करनी चाहिए और देखना चाहिए कि लोग इसे क्यों बनाते हैं और आप उन्हें आसानी से समझ सकते हैं।

उन दोनों को समझने के बाद, आप वास्तुकला शैलियों / पैटर्न की वस्तुओं को प्रोग्रामिंग प्रतिमानों से जोड़ सकते हैं।


2

मुझे लगता है कि वे अक्सर "बनाम" नहीं होते हैं, लेकिन आप उन्हें जोड़ सकते हैं। मुझे यह भी लगता है कि अक्सर, आपके द्वारा उल्लिखित शब्द केवल buzzwords हैं। बहुत कम लोग हैं जो वास्तव में जानते हैं कि "वस्तु-उन्मुख" का अर्थ क्या है, भले ही वे इसके कट्टर प्रचारक हों।


1

मेरा एक मित्र NVIDIA CUDA का उपयोग करके एक ग्राफिक्स ऐप लिख रहा है । आवेदन OOP प्रतिमान के साथ बहुत अच्छी तरह से फिट बैठता है और समस्या बड़े करीने से मॉड्यूल में विघटित हो सकती है। हालाँकि, CUDA का उपयोग करने के लिए आपको C का उपयोग करने की आवश्यकता होती है, जो वंशानुक्रम का समर्थन नहीं करता है । इसलिए, आपको चतुर होने की आवश्यकता है।

a) आप एक चतुर प्रणाली तैयार करते हैं जो एक निश्चित सीमा तक विरासत का अनुकरण करेगी। यह किया जा सकता है!

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

ii) आप बच्चों को माता-पिता में शामिल करने के लिए संरचित मेमोरी संरेखण सुविधा का उपयोग कर सकते हैं ।

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

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

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


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

2
@ क्रिस बेके आपका जवाब बहुत दार्शनिक है। एक के लिए, C के कई मानक हैं (वर्षों के माध्यम से), उनमें से कोई भी पूरी तरह से C कंपाइलर द्वारा पूरी तरह से अपनाया गया है अकेले c ++। यह कहने के लिए कि C ++ C का एक सुपरसेट है क्योंकि यह C सिंटैक्स का उपयोग नहीं करता है, इसका मतलब यह नहीं है क्योंकि आप एक C कंपाइलर के लिए कोड भी नहीं लिख सकते हैं जो महत्वपूर्ण प्रयास के बिना दूसरे C कंपाइलर में संकलित करता है। इसके अलावा, अन्य भाषाओं में भाषा सुविधाएँ (टाइप सिस्टम, OOD समर्थन) की पेशकश की जाती है, जो सी का उपयोग करने के बिना सी में एक नई भाषा को डिजाइन करने के लिए लागू करना असंभव होगा (जो वास्तव में 'नई भाषाएं' हैं)
स्प्रैग

तुम्हे पता हैं। मैं इस पोस्ट पर अपनी टिप्पणी से संबंधित किसी भी अधिक प्रासंगिकता को नहीं देख सकता। : पी
क्रिस बेके

Cuda ने पिछले कुछ समय से C ++ का समर्थन किया है।
आर्येह लीब तौआरोग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.