कार्यात्मक प्रोग्रामिंग बनाम ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग [बंद]

Question

मैं मुख्य रूप से OO प्रोग्रामिंग के लिए अब तक सामने आया हूं और एक कार्यात्मक भाषा सीखने के लिए उत्सुक हूं। मेरे प्रश्न हैं:

• आप ऑब्जेक्ट-ओरिएंटेड पर कार्यात्मक प्रोग्रामिंग कब चुनते हैं?
• विशिष्ट समस्या परिभाषाएं क्या हैं जहां कार्यात्मक प्रोग्रामिंग एक बेहतर विकल्प है?

Comments

डुप्लिकेट: stackoverflow.com/questions/552336/…

— gnovice

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

— ।stackexchange.com

इसी तरह के सवाल सेसे ने भी बंद कर दिया , उदाहरण है कि जहां कार्यात्मक प्रोग्रामिंग अनिवार्य शैली से बेहतर परिणाम देता है । पारंपरिक ज्ञान ऐसा लगता है कि एक दूसरे से बेहतर नहीं है, या वे सरल मानदंडों पर तुलनीय नहीं हैं, या यह कि वे विभिन्न उद्देश्यों के लिए उपयोग किए जाते हैं ... कार्यात्मक प्रोग्रामिंग में अधिक वैज्ञानिक / शैक्षणिक उत्पत्ति और उपयोग हैं और उद्योग में कम आम है , इसलिए यह सवाल एक "उद्योग बनाम शिक्षाविद" की स्थापना करता है। एक क्लासिक रेफरी जो कार्यात्मक प्रोग्रामिंग में ओओपी sytle दिखाता है, SICP पुस्तक / MIT

— vzn

" OO गतिमान भागों को कूटबद्ध कर कोड को समझने योग्य बनाता है। FP चलती भागों को कम करके कोड को समझने योग्य बनाता है। " - मिकाइल पंख, 2010

— jaco0646

Answer 1

आप ऑब्जेक्ट ओरिएंटेड पर कार्यात्मक प्रोग्रामिंग कब चुनते हैं?

जब आप एक अलग प्रकार के सॉफ़्टवेयर विकास का अनुमान लगाते हैं:

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

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

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

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

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

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

विशिष्ट समस्या परिभाषाएं क्या हैं जहां कार्यात्मक प्रोग्रामिंग एक बेहतर विकल्प है?

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

Comments

इस जवाब के पीछे कुछ गंभीर ज़ेन है। मुझे लगता है कि यह इस तथ्य को उजागर करता है कि कुछ ओओपी डिज़ाइन पैटर्न (विज़िटर) वास्तव में हैक हैं जो नए ऑपरेशन को जोड़ने की समस्या को दूर करने का प्रयास करते हैं।

— जैकब डेटा सॉल्यूशंस

जावास्क्रिप्ट में, आपके पास सभी चीजें हो सकती हैं।

— एरिक रिपेन

@ ErikReppen किस बिंदु पर सवाल उठता है, आप कब कार्यात्मक सुविधाओं का उपयोग करना चुनते हैं और कब आप ऑब्जेक्ट-ओरिएंटेड सुविधाओं का उपयोग करना चुनते हैं?

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

@NormanRamsey जेएस में इसे मिलाना बिल्कुल भी असामान्य नहीं है और प्रथम श्रेणी के फ़ंक्शंस बहुत सारे जेएस ओओपी-संबंधित सुविधाओं से जुड़े हैं। जेएस की सरणी छँटाई एक arg के रूप में कार्य करती है जो कुछ शक्तिशाली डेटा संरचनाओं का उत्पादन कर सकती है। क्लोजर + एक पारित फ़ंक्शन का उपयोग jquery वस्तुओं को बहुत हल्के स्मृति-बोलने के लिए किया जाता है क्योंकि अधिकांश विधियां केवल संदर्भ हैं। आदि ...

— एरिक रेपेन

@NormanRamsey: SICP की तर्ज पर बहुत अच्छा जवाब। इस वर्गीकरण के अनुसार, कार्यात्मक और प्रक्रियात्मक प्रोग्रामिंग को वस्तु-उन्मुख प्रोग्रामिंग के विपरीत पक्ष पर एक साथ समूहीकृत किया जाता है। यह 1990 के दशक के अंत में 1980 के दशक के अंत में OOP के उछाल की व्याख्या कर सकता है: जब GUI मुख्यधारा बन गए OOP उन्हें मॉडलिंग के लिए एक अच्छा दृष्टिकोण साबित हुआ क्योंकि आपके पास आमतौर पर संचालन का एक निश्चित सेट (पेंट, खुला, बंद, आकार) है और विजेट्स की बढ़ती संख्या। बेशक, इसका मतलब यह नहीं है कि ओओपी किसी भी आवेदन के लिए प्रक्रियात्मक से बेहतर है, जैसा कि आपने सचित्र किया है।

— जियोर्जियो

Answer 2

जरूरी नहीं कि आप दो प्रतिमानों के बीच चयन करें। आप कई कार्यात्मक अवधारणाओं का उपयोग करके एक ओओ आर्किटेक्चर के साथ सॉफ्टवेयर लिख सकते हैं। एफपी और ओओपी प्रकृति में रूढ़िवादी हैं ।

उदाहरण के लिए C # लें। आप कह सकते हैं कि यह ज्यादातर OOP है, लेकिन कई FP अवधारणाएं और निर्माण हैं। यदि आप Linq पर विचार करते हैं , तो सबसे महत्वपूर्ण निर्माण जो Linq को अस्तित्व में रखने की अनुमति देते हैं, प्रकृति में कार्यात्मक हैं: लंबोदर भाव ।

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

कई आधुनिक भाषाएं बहु प्रतिमान हैं।

अनुशंसित रीडिंग

जैसा कि मैं एक ही नाव में हूँ (ओओपी पृष्ठभूमि, एफपी सीख रहा है), मैं आपको कुछ रीडिंग सुझाता हूँ जिनकी मैंने वास्तव में सराहना की है:

• जेरेमी मिलर द्वारा हर रोज़ .NET विकास के लिए कार्यात्मक प्रोग्रामिंग । एक महान लेख (हालांकि खराब स्वरूपित) कई तकनीकों को दिखा रहा है और सी # पर एफपी के व्यावहारिक, वास्तविक दुनिया के उदाहरण हैं।

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

Comments

@duffymo: आपकी टिप्पणी, जिस तरह से आप इसे डालते हैं, वह ज्यादातर बेकार है। कोई भी भाषा, आभासी मशीनों या प्लेटफार्मों की तुलना नहीं चाहता है, धन्यवाद।

— ब्रूनो रीस

@ ब्रूनो - ".NET की शक्ति" की प्रतिक्रिया। आराम करें।

— duffymo

मजाकिया, मैं आपको डायकम को उसकी व्यर्थ टिप्पणी के बारे में नहीं बताता। क्या आप एक मध्यस्थ के रूप में नामांकित थे जबकि मैं नहीं देख रहा था? तुम्हारे सिवा यहाँ किसी की धज्जियाँ नहीं उड़ रही हैं। मैं इसे फिर से कहूँगा - आराम करो।

— duffymo

हेह, क्षमा करें अगर मैंने कुछ ज्वलंत शुरू किया। मेरे कहने का मतलब यह नहीं है कि अन्य प्लेटफ़ॉर्म कम शक्तिशाली हैं, बस .NET केवल OOP का समर्थन नहीं करता है। उदाहरण के लिए इसमें टेल कॉल ऑप्टिमाइज़ेशन है।

— डायकम

@nawfal, जब तक आप दो प्रतिमानों में कुछ आंतरिक विशेषताओं को इंगित कर सकते हैं और कह सकते हैं कि वे असंगत हैं, वे ऑर्थोगोनल हैं: यह चर्चा का दिल है। एफपी परिभाषा द्वारा अनिवार्य प्रोग्रामिंग के साथ असंगत है, लेकिन ओओपी अनिवार्य प्रोग्रामिंग तक सीमित नहीं है। इन अवधारणाओं के लिए हमारे पास अलग-अलग शब्द हैं, ताकि हम उनके बारे में बात कर सकें: जब आप उन्हें एक साथ लपकाते हैं, तो आप हमें अनावश्यक रूप से नए शब्दों के साथ आने के लिए मजबूर करते हैं।

— डेविड एफएस

Answer 3

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ऑफर:

1. एनकैप्सुलेशन, को
   • आंतरिक अवस्था का नियंत्रण उत्परिवर्तन
   • आंतरिक प्रतिनिधित्व को युग्मन सीमित करें
2. घटाना, अनुमति देना:
   • संगत प्रकारों का प्रतिस्थापन (बहुरूपता)
   • वर्गों के बीच कार्यान्वयन को साझा करने का एक क्रूड साधन (कार्यान्वयन विरासत)

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

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

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

Comments

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

— ज़क

Answer 4

1. यदि आप भारी समवर्ती वातावरण में हैं, तो शुद्ध कार्यात्मक प्रोग्रामिंग उपयोगी है। परस्पर अवस्था की कमी संगति को लगभग तुच्छ बना देती है। एर्लांग देखें।

2. एक बहुपक्षीय भाषा में, आप कुछ चीजों को कार्यात्मक रूप से मॉडल करना चाह सकते हैं यदि उत्परिवर्तनीय स्थिति का अस्तित्व कार्यान्वयन विवरण होना चाहिए, और इस प्रकार एफपी समस्या डोमेन के लिए एक अच्छा मॉडल है। उदाहरण के लिए, डी प्रोग्रामिंग भाषा में पायथन या std.range में सूची की समझ देखें । ये कार्यात्मक प्रोग्रामिंग से प्रेरित हैं।