ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, हम कह सकते हैं कोर अवधारणाओं हैं:कार्यात्मक प्रोग्रामिंग में मूल अवधारणाएं क्या हैं?
- कैप्सूलीकरण
- विरासत,
- बहुरूपता
क्या है कि कार्यात्मक प्रोग्रामिंग में हो सकता है?
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, हम कह सकते हैं कोर अवधारणाओं हैं:कार्यात्मक प्रोग्रामिंग में मूल अवधारणाएं क्या हैं?
क्या है कि कार्यात्मक प्रोग्रामिंग में हो सकता है?
कार्यात्मक प्रोग्रामिंग में आवश्यक अवधारणाओं पर कोई सामुदायिक सहमति नहीं है। Why Functional Programming Matters (PDF) में, जॉन ह्यूजेस का तर्क है कि वे उच्च-आदेश कार्य और आलसी मूल्यांकन हैं। Wearing the Hair Shirt: A Retrospective on Haskell में, साइमन पेटन जोन्स का कहना है कि असली आवश्यक आलस्य नहीं बल्कि शुद्धता है। रिचर्ड बर्ड सहमत होंगे। लेकिन योजना और एमएल प्रोग्रामर की पूरी भीड़ है जो साइड इफेक्ट्स के साथ प्रोग्राम लिखने में पूरी तरह से खुश हैं।
कोई है जो अभ्यास किया और बीस साल के लिए कार्यात्मक प्रोग्रामिंग सिखाया है, मैं तुम्हें कुछ विचार है कि व्यापक रूप से कार्यात्मक प्रोग्रामिंग के मूल में माना जाता है दे सकते हैं के रूप में:
नेस्ट, प्रथम श्रेणी फंक्शन उचित लेक्सिकल स्कोपिंग के साथ कोर पर हैं। इसका अर्थ यह है कि आप रन टाइम पर एक अनाम फ़ंक्शन बना सकते हैं, जिसका मुफ़्त चर फ़ंक्शन संलग्न करने वाले पैरामीटर या स्थानीय चर हो सकता है, और आपको वह मान मिलता है जिसे आप वापस कर सकते हैं, डेटा संरचनाओं में डाल सकते हैं, और इसी तरह। (यह उच्च क्रम कार्यों का सबसे महत्वपूर्ण रूप है, लेकिन कुछ उच्च क्रम कार्य (qsort
की तरह!) सी है, जो एक कार्यात्मक भाषा नहीं है में लिखा जा सकता है।) दूसरे के साथ काम करता है रचना की
साधन समस्याओं को हल करने के लिए कार्य करता है। जॉन ह्यूजेस से कोई भी बेहतर नहीं करता है।
कई कार्यात्मक प्रोग्रामर शुद्धता (उत्परिवर्तन, आई/ओ, और अपवाद सहित प्रभाव से स्वतंत्रता) कार्यात्मक प्रोग्रामिंग के मूल में हैं। कई कार्यात्मक प्रोग्रामर नहीं करते हैं।
पॉलिमॉर्फिज्म, चाहे यह संकलक द्वारा लागू किया गया हो या नहीं, कार्यात्मक प्रोग्रामर का मूल मूल्य है। उलझन में, सी ++ प्रोग्रामर इस अवधारणा को "जेनेरिक प्रोग्रामिंग" कहते हैं। जब संकलक द्वारा बहुरूपता लागू की जाती है तो यह आम तौर पर Hindley-Milner का एक रूप है, लेकिन अधिक शक्तिशाली System F कार्यात्मक भाषाओं के लिए भी एक शक्तिशाली आधार है। और स्कीम, एरलांग और लुआ जैसी भाषाओं के साथ, आप एक स्थिर प्रकार प्रणाली के बिना कार्यात्मक प्रोग्रामिंग कर सकते हैं।
अंत में, कार्यात्मक प्रोग्रामर की एक बड़ी संख्या उपपादन द्वारा परिभाषित डेटा प्रकार का मूल्य, कभी कभी "पुनरावर्ती प्रकार" कहा जाता है में विश्वास करते हैं। स्थिर प्रकार प्रणालियों वाली भाषाओं में इन्हें आम तौर पर "बीजगणित डेटा प्रकार" के रूप में जाना जाता है, लेकिन आपको material written for beginning Scheme programmers में भी अनिवार्य रूप से परिभाषित डेटा प्रकार मिलेंगे। अनिवार्य रूप से परिभाषित प्रकार आमतौर पर पैटर्न नामक एक भाषा सुविधा के साथ शिप करते हैं, जो केस विश्लेषण के एक बहुत ही सामान्य रूप का समर्थन करता है। अक्सर संकलक आपको बता सकता है कि क्या आप एक मामला भूल गए हैं। मैं इस भाषा सुविधा के बिना प्रोग्राम नहीं करना चाहता (एक लक्जरी एक बार नमूना एक आवश्यकता बन जाती है)।
एक कार्यात्मक कार्यक्रम केवल कार्यों के होते हैं:
मुझे लगता है कि बहुरूपता एक भ्रामक है। सी ++ में जेनेरिक प्रोग्रामिंग इस से बहुत अधिक कवर करता है (यह आम तौर पर प्रकार के आधार पर कई अलग-अलग कार्यान्वयन को सक्षम करने के लिए मेटाप्रोग्रामिंग का भी उपयोग करता है - आप जो बात कर रहे हैं वह सी ++ टेम्पलेट्स/जेनेरिक प्रोग्रामिंग की तुलना में .NET जेनेरिक के समान है)।और पैरामीट्रिक प्रकार पॉलीमोर्फिज्म के इस रूप में ओओपी प्रोग्रामर पॉलीमोर्फिज्म को कॉल करने के साथ बहुत कम नहीं है। यदि आप इसे पॉलिमॉर्फिक प्रकार कहते हैं, तो मुझे लगता है कि यह स्पष्ट हो गया होगा। – jalf
@ नॉर्मन रैमसे - मुझे यह पसंद है कि आपने शुद्धता बुलाई है और मुझे यह स्वीकार करना होगा कि मैंने पहले यह नहीं सुना था कि कार्यात्मक प्रोग्रामिंग बहुरूपता का प्रतीक है। मुझे लगता है कि मेरा जवाब कार्यात्मक प्रोग्रामिंग के मांस के लिए सही हो जाता है लेकिन मुझे आपके लेखन को जानकारीपूर्ण मिला। धन्यवाद। –
कंप्यूटर विज्ञान में, कार्यात्मक प्रोग्रामिंग एक प्रोग्रामिंग प्रतिमान है जो गणना को गणितीय कार्यों के मूल्यांकन के रूप में मानता है और राज्य और परिवर्तनीय डेटा से बचाता है। यह अनिवार्य प्रोग्रामिंग शैली के विपरीत कार्यों के अनुप्रयोग पर जोर देता है, जो राज्य में बदलावों पर जोर देता है। कार्यात्मक प्रोग्रामिंग की जड़ें लैम्ब्डा कैलकुस में होती हैं, जो औपचारिक प्रणाली को 1 9 30 के दशक में फ़ंक्शन परिभाषा, फ़ंक्शन एप्लिकेशन और रिकर्सन की जांच करने के लिए विकसित की जाती है। कई कार्यात्मक प्रोग्रामिंग भाषाओं को लैम्ब्डा कैलकुस के लिए सजावट के रूप में देखा जा सकता है। - Wikipedia
संक्षेप में,
एब्स्ट्रक्शन, एक अभिव्यक्ति के कुछ हिस्सों पर पैरामीटर करके एक फ़ंक्शन बनाने की प्रक्रिया।
आवेदन, विशिष्ट मानों के साथ अपने पैरामीटर को प्रतिस्थापित करके फ़ंक्शन का मूल्यांकन करने की प्रक्रिया।
कुछ स्तर पर, यह सब कुछ है।
वास्तव में, वास्तव में एफपी के लिए बहुत कुछ नहीं है। –
सीधे आपके प्रश्न का उत्तर नहीं है, लेकिन मैं यह इंगित करना चाहता हूं कि "ऑब्जेक्ट उन्मुख" और कार्यात्मक प्रोग्रामिंग अनिवार्य रूप से बाधाओं पर नहीं हैं। आपके द्वारा उद्धृत "मूल अवधारणाओं" में अधिक सामान्य समकक्ष होते हैं जो कार्यात्मक प्रोग्रामिंग के साथ ही लागू होते हैं।
Encapsulation, आमतौर पर, मॉड्यूलरिसेशन है। सभी विशुद्ध रूप से कार्यात्मक भाषाएं जिन्हें मैं समर्थन के बारे में जानता हूं मॉड्यूलर प्रोग्रामिंग। आप कह सकते हैं कि वे भाषाएं सामान्य "ओओ" किस्म से बेहतर encapsulation लागू करती हैं, क्योंकि दुष्प्रभाव ब्रेक encapsulation, और शुद्ध कार्यों का कोई दुष्प्रभाव नहीं है।
विरासत, आमतौर पर तार्किक निहितार्थ है, जो एक फ़ंक्शन का प्रतिनिधित्व करता है। कैननिकल subclass -> superclass
संबंध एक प्रकार का निहित कार्य है। कार्यात्मक भाषाओं में, यह प्रकार वर्ग या के साथ व्यक्त किया गया है (मैं इन दोनों के अधिक सामान्य होने के लिए प्रत्याशित मानता हूं)।
"ओओ" स्कूल में पॉलिमॉर्फिज्म उप प्रकार (विरासत) के माध्यम से हासिल किया जाता है। पैरामीट्रिक पॉलिमॉर्फिज्म (ए.के.ए.ए. के रूप में जाना जाने वाला एक सामान्य प्रकार का बहुरूपता है।जेनेरिक), जिसे आप शुद्ध-कार्यात्मक प्रोग्रामिंग भाषाओं द्वारा समर्थित पाएंगे। इसके अतिरिक्त, कुछ समर्थन "उच्च प्रकार", या उच्च-आदेश जेनरिक (ए.के.ए. प्रकार कन्स्ट्रक्टर पॉलीमोर्फिज्म)।
मैं जो कहने की कोशिश कर रहा हूं वह यह है कि आपकी "ओओ की मूल अवधारणाएं" किसी भी तरह से ओओ के लिए विशिष्ट नहीं हैं। मैं, एक के लिए, तर्क दूंगा कि वास्तव में ओओ की मूल अवधारणाओं को नहीं है।
इसे सेकेंड करना, ओओ और कार्यात्मक एक साथ काम कर सकते हैं। कुछ कार्यात्मक भाषा (सीएएमएल, या ओसीएएमएल विशिष्ट होना) ओओ अवधारणाओं में खींचें और कुछ ओओ भाषाएं (जैसे डी और यहां तक कि सी #) कार्यात्मक अवधारणाओं का उपयोग करें। मैं कहूंगा कि "ऑब्जेक्ट्स" हालांकि ओओ प्रोग्रामिंग के विचार के लिए बहुत महत्वपूर्ण हैं। ;) – CodexArcanum
फिर आपको बस "ऑब्जेक्ट" वास्तव में परिभाषित करने की समस्या है, और यह उन चीजों से अलग कैसे है जो वस्तुओं नहीं हैं। सौभाग्य। – Apocalisp
मुझे जवाब मैं बंगलौर कार्यात्मक प्रोग्रामिंग समूह में एक चर्चा में दे दी है दोहराएँ।कार्य उनके इनपुट से मान गणना करते हैं। हम अनिवार्य प्रोग्रामिंग के साथ इसके विपरीत कर सकते हैं, जहां प्रोग्राम निष्पादित होता है, परिवर्तनीय स्थानों के मान बदलते हैं। दूसरे शब्दों में, सी या जावा में, एक्स नामक एक चर को उस स्थान से संदर्भित किया जाता है जिसका मान बदलता है। लेकिन कार्यात्मक प्रोग्रामिंग एक्स में मान का नाम है (कोई स्थान नहीं)। कोई भी जहां एक्स दायरे में है, तो यह वही मान है (यानी, यह संदर्भित रूप से पारदर्शी है)। एफपी में, कार्य भी मूल्य हैं। उन्हें अन्य कार्यों के लिए तर्क के रूप में पारित किया जा सकता है। इसे उच्च-आदेश कार्यात्मक प्रोग्रामिंग के रूप में जाना जाता है। उच्च-आदेश फ़ंक्शन हमें पैटर्न की एक अद्भुत विविधता मॉडल करने देते हैं। उदाहरण के लिए, लिस्प में मानचित्र फ़ंक्शन देखें। यह एक पैटर्न का प्रतिनिधित्व करता है जहां प्रोग्रामर को सूची के प्रत्येक तत्व को पर 'कुछ' करने की आवश्यकता होती है। उस 'कुछ' को फ़ंक्शन के रूप में एन्कोड किया गया है और मानचित्र के लिए तर्क के रूप में पारित किया गया है।
जैसा कि हमने देखा, एफपी की सबसे उल्लेखनीय विशेषता यह है कि इसका दुष्प्रभाव उन्नीस है। यदि कोई फ़ंक्शन किसी इनपुट को उसके इनपुट से गणना करने से कुछ और करता है, तो यह दुष्प्रभाव पैदा कर रहा है। इस तरह के कार्यों को शुद्ध एफपी में की अनुमति नहीं है। दुष्प्रभाव मुक्त कार्यों का परीक्षण करना आसान है। परीक्षण चलाने से पहले सेट अप करने के लिए कोई वैश्विक स्थिति नहीं है और वहां परीक्षण चलाने के बाद कोई वैश्विक स्थिति नहीं है। प्रत्येक फ़ंक्शन को केवल इनपुट प्रदान करके और वापसी मूल्य की जांच करके स्वतंत्र रूप से परीक्षण किया जा सकता है। यह स्वचालित परीक्षण लिखना आसान बनाता है। दुष्प्रभाव पर एक अन्य लाभ यह है कि यह आपको समांतरता पर पर बेहतर नियंत्रण देता है।
कई एफपी भाषाएं रिकर्सन और पुनरावृत्ति का सही ढंग से इलाज करती हैं। वे द्वारा पूंछ-रिकर्सन नामक कुछ का समर्थन करते हैं। पूंछ-रिकर्सन क्या है - यदि फ़ंक्शन स्वयं कॉल करता है, और यह आखिरी चीज है, तो यह वर्तमान स्टैक फ्रेम को तुरंत हटा देता है। दूसरे शब्दों में, यदि फ़ंक्शन स्वयं को 1000 बार बार-बार कॉल करता है, तो यह स्टैक 1000 गुना नहीं बढ़ता है। इससे विशेष लूपिंग इन भाषाओं में अनावश्यक बनाती है।
लैम्ब्डा कैलकुस एक एफपी भाषा का सबसे उबला हुआ संस्करण है। हास्केल जैसे उच्च स्तर की एफपी भाषाओं को लैम्ब्डा कैलकुस में संकलित किया जाता है। इसमें केवल तीन सिंटेक्टिक संरचनाएं हैं लेकिन फिर भी यह किसी भी अमूर्तता या एल्गोरिदम का प्रतिनिधित्व करने के लिए पर्याप्त अभिव्यक्तिपूर्ण है।
मेरी राय यह है कि एफपी को मेटा-प्रतिमान के रूप में देखा जाना चाहिए। हम लैम्ब्डा कैलकुस द्वारा प्रदान किए गए सरल कार्यात्मक अबास्ट्रक्शन का उपयोग करके ओओपी समेत किसी भी शैली में प्रोग्राम लिख सकते हैं।
धन्यवाद, - विजय
मूल चर्चा लिंक: http://groups.google.co.in/group/bangalore-fp/browse_thread/thread/4c2cfa7985d7eab3
आप विश्वास है क्यों कि उन OOP के मूल अवधारणाओं रहे हैं? कई ओओ भाषाओं में encapsulation नहीं है (उदाहरण के लिए पायथन, सीएलओएस)। कुछ ओओ भाषाओं में विरासत नहीं होती है (जैसे स्वयं, जावास्क्रिप्ट, और कोई अन्य प्रोटोटाइप-आधारित भाषा), और कुछ करते हैं लेकिन यह इतना बड़ा सौदा नहीं है (लगभग किसी भी गतिशील भाषा, या बतख टाइपिंग वाली कोई अन्य भाषा)। एकमात्र चीज जो उन सभी के लिए वास्तव में आम है, रनटाइम बहुरूपता है। –
विकिपीडिया से: "आर्मस्ट्रांग, ऑब्जेक्ट ओरिएंटेड डेवलपमेंट के क्वार्क।लोकप्रियता के अवरोही क्रम में, "क्वार्क" हैं: विरासत, वस्तु, कक्षा, Encapsulation, विधि, संदेश उत्तीर्ण, बहुरूपता, एब्स्ट्रक्शन " – Nosredna
नोस्रेना, और उनमें से एक भी सटीक अर्थ नहीं है। – Apocalisp