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

93

मैंने हास्केल जैसे कार्यात्मक भाषाओं का उपयोग करने के बारे में बहुत सारी बातें सुनी हैं। कार्यात्मक प्रोग्रामिंग बनाम वस्तु-उन्मुख प्रोग्रामिंग के बड़े अंतर, पेशेवरों और विपक्षों में से कुछ क्या हैं?

object-oriented functional-programming

— GSto
स्रोत

27

एक दूसरे को अस्वीकार नहीं करता है।

— mbq

1

@ मुझे लगता है कि वे परस्पर अनन्य नहीं हैं, लेकिन मैं सिर्फ दो दृष्टिकोणों के अंतर की बेहतर समझ प्राप्त करने की कोशिश करना चाहता था।

— GSto

बड़ा सवाल है। मैं इस बारे में भी सोच रहा हूं।

— जॉन एफएक्स

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

— लापता

4

असली उत्तर है - उनके बीच में "बनाम" नहीं है। की जाँच करें StackOverflow पर इस सवाल का ।

— 3

67

मैं कहूंगा कि यह अधिक कार्यात्मक प्रोग्रामिंग बनाम इंपीरियल प्रोग्रामिंग है ।

सबसे बड़ा अंतर यह है कि इंपीरियल प्रोग्रामिंग नियंत्रण प्रवाह के बारे में है जबकि कार्यात्मक प्रोग्रामिंग डेटा प्रवाह के बारे में है । यह कहने का एक और तरीका यह है कि कार्यात्मक प्रोग्रामिंग केवल अभिव्यक्तियों का उपयोग करती है जबकि अनिवार्य प्रोग्रामिंग में अभिव्यक्ति और कथन दोनों का उपयोग किया जाता है।

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

एक सूची के योग की गणना के लिए एक फ़ंक्शन के लिए इंपीरियल छद्म कोड (एक चर में योग रखा गया है):

int sumList(List<int> list) {
    int sum = 0;
    for(int n = 0; n < list.size(); n++) {
        sum = sum + list.get(n);
    }

    return sum;
}

समान फ़ंक्शन के लिए कार्यात्मक छद्म कोड (योग एक पैरामीटर के रूप में पारित किया जाता है):

fun sumList([], sum) = sum
 |  sumList(v::lst, sum) = sumList(lst, v+sum)

मैं कार्यात्मक अवधारणाओं के अच्छे परिचय के लिए साइमन पेटन-जोन्स द्वारा कार्यात्मक प्रोग्रामिंग के साथ प्रस्तुति टैमिंग प्रभाव की सिफारिश करता हूं ।

— जोनास
स्रोत

12

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

— वैकल्पिक

3

कार्यात्मक बनाम कार्यात्मक के सबसे महत्वपूर्ण पहलू का वर्णन करने के लिए +1: डेटा प्रवाह बनाम नियंत्रण प्रवाह। मुझे एक बात यह जोड़ना है कि कार्यात्मक प्रतिमान और OO प्रतिमान परस्पर अनन्य नहीं है ; आप OO प्रतिमान का उपयोग इस बात के लिए कर सकते हैं कि कैसे ऑब्जेक्ट (डेटा) इंटरैक्ट करता है, और उस ऑब्जेक्ट को बदलने (हेरफेर) करने के लिए कार्यात्मक प्रतिमान।

— झूठ रेयान

1

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

— कोडेक्सआर्केनम

मुझे लगता है कि यह भी ध्यान देने योग्य है कि मुख्य अंतर यह नहीं है कि आप एक ही कार्यक्रम लिखते हैं, लेकिन आप अपने लूप्स को पुनरावृत्ति करने वाले तरीके से कॉल करते हैं। यह उस से भी बड़ा है

— सारा

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

— दाई

16

कार्यात्मक प्रोग्रामिंग एक घोषणात्मक मॉडल पर आधारित है और इसकी जड़ें लैम्ब्डा कैलकुलस से हैं। यह बहुत सी बेहतरीन अवधारणाएँ प्रदान करता है जिन्हें C ++ और C # जैसी अधिक अनिवार्य भाषाओं से उधार लिया जा सकता है।

कुछ उदाहरणों में संदर्भित पारदर्शिता, लैम्ब्डा फ़ंक्शंस, प्रथम श्रेणी फ़ंक्शंस, आलसी और उत्सुक मूल्यांकन, और अपरिवर्तनीयता शामिल हैं।

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

आरंभ करने के लिए आप एक शुद्ध कार्यात्मक भाषा जैसे हास्केल का उपयोग करने के लिए चुना जा सकता है, या आप F # की तरह एक संकर का उपयोग कर सकते हैं ।

अधिकांश अच्छे विश्वविद्यालय कार्यात्मक प्रोग्रामिंग को कवर करेंगे और अगर आप स्कूल जाते हैं तो मैं आपको अत्यधिक सुझाव दूंगा कि आप यह कोर्स करें।

कार्यात्मक प्रोग्रामिंग बनाम वस्तु-उन्मुख प्रोग्रामिंग के बड़े अंतर, पेशेवरों और विपक्षों में से कुछ क्या हैं?

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

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

— ब्रायन आर बॉडी
स्रोत

2

स्पष्ट होने के लिए, यह योजना किसी भी तरह से शुद्ध कार्यात्मक भाषा नहीं है।

— जोनाथन स्टर्लिंग

5

आपका दूसरा अंतिम पैराग्राफ पूरी तरह से bs है। OO मल्टीथ्रेडिंग में किसी भी समस्या का सामना नहीं करता है, पारस्परिकता करता है। आप ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के साथ जरूरी प्रोग्रामिंग को भ्रमित करने लगते हैं। क्या यह मामला है?

— लापता

5

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

— ब्रायन आर। बॉडी

आपको इस प्रश्न का उत्तर पढ़ना चाहिए: stackoverflow.com/questions/3949618/fp-and-oo-orthogonal/…

— ak ak

फ्रैंक

— शीयर

8

(यह उत्तर StackOverflow पर एक बंद प्रश्न के उत्तर से अनुकूलित है ।)

कार्यात्मक प्रोग्रामिंग और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के बीच एक बड़ा अंतर यह है कि प्रत्येक एक अलग तरह के सॉफ़्टवेयर विकास में बेहतर है:

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

जब विकास गलत तरीके से होता है, तो आपको समस्याएं होती हैं:

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

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

— नॉर्मन रैमसे
स्रोत

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

— तबीअक to to

4

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

एफपी भाषाओं के उपयोगकर्ता गणितीय कानूनों के माध्यम से प्रतिरूपकता प्राप्त करते हैं। और अपने कानूनों के अनुपालन को दिखाने के लिए प्रमाण देना पसंद करते हैं।

अत्यावश्यक OOP में उपयोगकर्ता परीक्षण-मामलों में वस्तु के व्यवहार को पकड़ते हैं, जो कि वस्तु को इस तरह से रूपांतरकता में बदल देने और प्राप्त करने पर फिर से हो सकता है।

यह सिर्फ एक छोटा सा पहलू है, लेकिन मुझे लगता है कि यह ध्यान देने योग्य है।

— एडगर क्लार्क
स्रोत

2

एक सादृश्य:

आपको नौकरी का आवेदन सौंपा गया है। आप अपना नाम, संपर्क जानकारी और कार्य इतिहास भरें। जब आप समाप्त कर लेते हैं तो आपके पास कोई रिक्त एप्लिकेशन नहीं होता है।

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

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

— मारियो टी। लैंज़ा
स्रोत

सुंदर सादृश्य, thx !! क्या आप (यदि संभव हो तो) इन दोनों दृष्टिकोणों में पेशेवरों और विपक्ष के साथ इस सादृश्य का विस्तार करेंगे।

— राहुल अग्रवाल