क्या कार्यात्मक प्रोग्रामिंग वस्तु का सुपरसेट है?

Question

जितनी अधिक कार्यात्मक प्रोग्रामिंग मैं करता हूं, उतना ही मुझे लगता है कि यह अमूर्तता की एक अतिरिक्त परत जोड़ता है जो ऐसा लगता है कि एक प्याज की परत कैसी है- पिछली परतों के सभी शामिल हैं।

मुझे नहीं पता कि यह सच है इसलिए मैंने जिन ओओपी सिद्धांतों पर सालों से काम किया है, क्या कोई यह बता सकता है कि कोई व्यक्ति कैसे कार्य करता है या उनमें से किसी को भी सटीक रूप से चित्रित नहीं करता है: एनकैप्सुलेशन, एब्सट्रैक्शन, इनहेरिटेंस, पॉलिमॉर्फिज्म

मुझे लगता है कि हम सभी कह सकते हैं, हाँ इसमें ट्यूपल्स के माध्यम से एनकैप्सुलेशन है, या ट्यूपल्स को तकनीकी रूप से "कार्यात्मक प्रोग्रामिंग" के तथ्य के रूप में गिना जाता है या वे सिर्फ भाषा की उपयोगिता हैं?

मुझे पता है कि हास्केल "इंटरफेस" आवश्यकता को पूरा कर सकता है, लेकिन फिर से निश्चित नहीं है अगर यह विधि कार्यात्मक का एक तथ्य है? मैं यह अनुमान लगा रहा हूं कि फंक्शनलर्स के पास एक गणितीय आधार होता है जो आप कह सकते हैं कि वे एक निश्चित रूप से कार्यात्मक की उम्मीद में बनाए गए हैं, शायद?

कृपया, आपको लगता है कि कार्यात्मक कैसे करता है या ओओपी के 4 सिद्धांतों को पूरा नहीं करता है।

संपादित करें: मैं कार्यात्मक प्रतिमान और वस्तु उन्मुख प्रतिमान के बीच के अंतरों को ठीक-ठीक समझता हूं और महसूस करता हूं कि इन दिनों बहुपक्षीय भाषाएं हैं जो दोनों कर सकती हैं। मैं वास्तव में सिर्फ एकमुश्त fp (थिंक प्यूरीस्ट, जैसे हैस्केल) की परिभाषाएँ देख रहा हूँ कि कोई भी 4 चीजें सूचीबद्ध कर सकता है, या यह उनमें से कोई भी क्यों नहीं कर सकता है। अर्थात "एनकैप्सुलेशन को बंद करने के साथ किया जा सकता है" (या यदि मैं इस विश्वास में गलत हूं, तो कृपया बताएं कि क्यों)।

Comments

वे 4 सिद्धांत "ओओपी" नहीं बनाते हैं। OOP बस वर्गों, वर्ग hiearchy और उनके उदाहरणों के उपयोग से "हल" करता है। लेकिन मैं भी एक उत्तर चाहूंगा कि अगर कार्यात्मक प्रोग्रामिंग में उन लोगों को प्राप्त करने के तरीके हैं।

— व्यंग्यात्मक

परिभाषा के आधार पर @Euphoric, यह पड़ता है OOP।

— कोनराड रुडोल्फ

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

@KonradRudolph यह किसी भी अधिक स्वीकार्य नहीं है। यदि कुछ भी है, तो यह कदम बढ़ाने और इसे फिर से विचार करने के लिए इसे फैलाने वालों को देने के लिए प्रोत्साहन है।

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

— सद्दाम

Answer 1

कार्यात्मक प्रोग्रामिंग OOP से ऊपर की परत नहीं है; यह पूरी तरह से अलग प्रतिमान है। ओओपी को एक कार्यात्मक शैली में करना संभव है (एफ # इस उद्देश्य के लिए लिखा गया था), और स्पेक्ट्रम के दूसरे छोर पर आपके पास हास्केल जैसे सामान हैं, जो स्पष्ट रूप से ऑब्जेक्ट ओरिएंटेशन के सिद्धांतों को अस्वीकार करता है।

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

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

Comments

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

— एसके-तर्क

इसे नकली बनाना हमेशा संभव है - आप अपने द्वारा चुनी गई किसी भी भाषा में वस्तुओं को लागू कर सकते हैं। मैं हालांकि बाकी सब से सहमत हूं :)

— एलियट बॉल

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

— sepp2k

@ sepp2k: उन्होंने यह नहीं कहा कि उन्होंने इस शब्द का आविष्कार किया है, बस वे इसे लगभग एक ही स्वर का उपयोग करके मिटा देते हैं क्योंकि आमतौर पर उन बच्चों को संदर्भित करने के लिए उपयोग किया जाता है जो अपने लॉन से बाहर निकलने से इनकार करते हैं।

— हारून

@Aaronaught यह मेरे लॉन के बच्चे नहीं हैं जो मुझे परेशान करते हैं, यह उनके खूनी दुष्प्रभाव हैं! अगर वे सिर्फ मेरे लॉन पर सभी को बदलना बंद कर देंगे तो मैं उन्हें बिल्कुल भी बुरा नहीं मानूंगा।

— जिमी हॉफ

Answer 2

मुझे OOP और FP की तुलना करने के लिए निम्नलिखित अंतर्ज्ञान उपयोगी लगते हैं।

एफपी को ओओपी के सुपरसेट के रूप में विचार करने के बजाय, ओओपी और एफपी को एक समान अंतर्निहित गणना मॉडल को देखने के दो वैकल्पिक तरीकों के रूप में सोचें, जिसमें आपके पास है:

1. कुछ ऑपरेशन जो निष्पादित किए जाते हैं,
2. ऑपरेशन के लिए कुछ इनपुट तर्क,
3. कुछ निश्चित डेटा / पैरामीटर जो ऑपरेशन की परिभाषा को प्रभावित कर सकते हैं,
4. कुछ परिणाम मूल्य, और
5. संभवतः एक साइड-इफेक्ट।

OOP में यह द्वारा कब्जा कर लिया है

1. एक विधि जिसे निष्पादित किया जाता है,
2. एक विधि के इनपुट तर्क,
3. वह वस्तु जिस पर विधि लागू होती है, जिसमें सदस्य चर के रूप में कुछ स्थानीय डेटा होते हैं,
4. विधि की वापसी मूल्य (संभवतः शून्य),
5. विधि के दुष्प्रभाव।

एफपी में यह द्वारा कब्जा कर लिया है

1. एक क्लोजर जिसे निष्पादित किया जाता है,
2. क्लोजर के इनपुट तर्क,
3. बंद के चर पर कब्जा कर लिया,
4. क्लोजर का रिटर्न मान,
5. बंद करने के संभावित दुष्प्रभाव (हास्केल जैसी शुद्ध भाषाओं में, यह बहुत नियंत्रित तरीके से होता है)।

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

मुझे लगता है कि अलग-अलग दृष्टिकोण इस तथ्य से उत्पन्न होते हैं कि ऑब्जेक्ट-ओरिएंटेड दृश्य ऑब्जेक्ट्स (डेटा) पर केंद्रित है, जबकि कार्यात्मक दृश्य फ़ंक्शन / क्लोजर (संचालन) पर केंद्रित है।

Answer 3

यह निर्भर करता है कि आप OOP की परिभाषा किससे पूछते हैं। पाँच लोगों से पूछें और आपको छह परिभाषाएँ मिलेंगी। विकिपीडिया कहता है :

वस्तुओं के पीछे सर्वसम्मति की परिभाषा या सिद्धांत को खोजने का प्रयास बहुत सफल साबित नहीं हुआ है

इसलिए जब भी कोई बहुत ही निश्चित उत्तर दे तो उसे नमक के दाने के साथ लें।

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

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

var cls = function (x) {
    this.y = x;
    this.fun = function () { alert(this.y); };
    return this;
};

var inst = new cls(42);
inst.fun();

(बेशक जावास्क्रिप्ट म्यूटिंग मूल्यों की अनुमति देता है जो विशुद्ध रूप से कार्यात्मक प्रोग्रामिंग में अवैध है लेकिन न ही ओओपी की सख्त परिभाषा में इसकी आवश्यकता है।)

हालांकि अधिक महत्वपूर्ण प्रश्न यह है: क्या यह ओओपी का एक सार्थक वर्गीकरण है? क्या यह कार्यात्मक प्रोग्रामिंग के सबसेट के रूप में सोचने में सहायक है? मुझे लगता है कि ज्यादातर मामलों में, ऐसा नहीं है।

Comments

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

— जिमी होफा

Answer 4

OO की तरह FP अच्छी तरह से परिभाषित शब्द नहीं है। अलग-अलग, कभी-कभी परस्पर विरोधी, परिभाषा वाले स्कूल होते हैं। यदि आप वे लेते हैं जो उनके पास समान हैं, तो आप नीचे आते हैं:

• कार्यात्मक प्रोग्रामिंग प्रथम श्रेणी के कार्यों के साथ प्रोग्रामिंग है

• OO प्रोग्रामिंग गतिशील रूप से हल किए गए ओवरलोडिंग के कम से कम एक प्रतिबंधित रूप के साथ संयुक्त समावेशन बहुरूपता के साथ प्रोग्रामिंग है । (ए साइड नोट: ओओ सर्किलों में बहुरूपता आमतौर पर समावेशी बहुरूपता का अर्थ लिया जाता है , जबकि एफपी स्कूलों का आमतौर पर अर्थ पैरामीट्रिक बहुरूपता होता है।)

बाकी सब चीजें या तो कहीं और मौजूद हैं, या कुछ मामलों में अनुपस्थित हैं।

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

Comments

मुझे लगता है कि आप 'प्रथम श्रेणी के कार्यों' के बजाय 'प्रथम श्रेणी के कार्यों' से मतलब रखते हैं।

— dan_waterworth

Errr ... C ++ 11 लैम्ब्डा शायद ही प्रथम श्रेणी के कार्य हैं: प्रत्येक लैम्बडा का अपना स्वयं का एड-हॉक प्रकार है (सभी व्यावहारिक उद्देश्यों के लिए, एक अनाम संरचना), जो मूल फ़ंक्शन पॉइंटर प्रकार के साथ असंगत है। और std::function, जिसमें फंक्शन पॉइंटर्स और लैम्ब्डा दोनों को असाइन किया जा सकता है, निश्चित रूप से सामान्य है, ऑब्जेक्ट-ओरिएंटेड नहीं। यह कोई आश्चर्य की बात नहीं है, क्योंकि ऑब्जेक्ट-ओरिएंटेशन का सीमित ब्रांड पॉलीमॉर्फिज्म (उपप्रकार पॉलीमॉर्फिज्म) पैरामीट्रिक पॉलीमॉर्फिज्म (यहां तक ​​कि हिंडले-मिलनर, अकेले फुल सिस्टम एफ-ओमेगा) की तुलना में कम शक्तिशाली है।

— pyon

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

— एरिक रेपेन

Answer 5

नहीं; OOP को प्रक्रियात्मक प्रोग्रामिंग के सुपरसेट के रूप में देखा जा सकता है और कार्यात्मक प्रतिमान से मौलिक रूप से भिन्न होता है क्योंकि यह उदाहरण क्षेत्रों में राज्य का प्रतिनिधित्व करता है। कार्यात्मक प्रतिमान में चर कार्य होते हैं जो वांछित परिणाम प्राप्त करने के लिए निरंतर डेटा पर लागू होते हैं।

वास्तव में आप कार्यात्मक प्रोग्रामिंग को OOP का सबसेट मान सकते हैं; यदि आप अपनी सभी कक्षाओं को अपरिवर्तनीय बनाते हैं, तो आप विचार कर सकते हैं कि आपके पास किसी प्रकार की कार्यात्मक प्रोग्रामिंग है।

Comments

अपरिवर्तनीय कक्षाएं उच्च क्रम के कार्य, सूची की समझ, या बंद करने की व्यवस्था नहीं करती हैं। Fp एक सबसेट नहीं है।

— जिम्मी हॉफ

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

— m3th0dman

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

— जिमी हॉफ

हाँ, लेकिन अगर उपयोग स्थिति को बदलने के लिए क्लोजर का उपयोग करें, तो क्या आप अभी भी एक कार्यात्मक प्रतिमान में कार्यक्रम करेंगे? बिंदु है - कार्यात्मक प्रतिमान उच्च-क्रम के कार्यों, पुनरावृत्ति या बंद होने के बारे में नहीं बल्कि राज्य की कमी के बारे में है।

— m3th0dman 18

fp की परिभाषा पर दिलचस्प विचार .. मुझे इस बारे में अधिक सोचना होगा, आपकी टिप्पणियों को साझा करने के लिए धन्यवाद।

— जिमी होफा

Answer 6

उत्तर:

विकिपीडिया में आपके द्वारा पूछे गए कुछ उदाहरणों के साथ कार्यात्मक प्रोग्रामिंग पर एक शानदार लेख है । @ कोनराड रुडोल्फ ने पहले ही ओओपी लेख का लिंक प्रदान किया ।

मुझे नहीं लगता कि एक प्रतिमान दूसरे का एक सुपर-सेट है। वे प्रोग्रामिंग पर अलग-अलग दृष्टिकोण हैं और कुछ समस्याओं को एक परिप्रेक्ष्य से और कुछ दूसरे से बेहतर हल किया जाता है।

एफपी और ओओपी के सभी कार्यान्वयनों से आपका प्रश्न और अधिक जटिल है । प्रत्येक भाषा के अपने प्रश्न हैं जो आपके प्रश्न के किसी भी अच्छे उत्तर के लिए प्रासंगिक हैं।

तेजी से बढ़ती जुआ:

मुझे यह विचार पसंद है कि स्काला जैसी भाषा आपको दोनों दुनिया में सर्वश्रेष्ठ देने की कोशिश करती है। मुझे चिंता है कि यह आपको दोनों दुनिया की जटिलताओं के बारे में बताता है।

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

public class ClosureTry implements AutoCloseable {

    public static void main(String[] args) {
        int a = 1;
        try(ClosureTry ct = new ClosureTry()) {
            System.out.println("Middle Stuff...");
            a = 2;
        }
        System.out.println("a: " + a);
    }

    public ClosureTry() {
        System.out.println("Start Stuff Goes Here...");
    }

    /** Interface throws exception, but we don't have to. */
    public void close() {
        System.out.println("End Stuff Goes Here...");
    }
}

आउटपुट:

Start Stuff Goes Here...
Middle Stuff...
End Stuff Goes Here...
a: 2

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

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

मेरे लिए, ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के सबसे उपयोगी हिस्से डेटा हाइडिंग (एनकैप्सुलेशन) हैं, समान (पॉलीमॉर्फिज़्म) के समान-समान ऑब्जेक्ट्स का इलाज करते हैं, और आपके डेटा और विधियों को इकट्ठा करते हैं जो उस डेटा (ऑब्जेक्ट्स / क्लासेस) पर एक साथ काम करते हैं। वंशानुक्रम OOP का प्रमुख हो सकता है, लेकिन मेरे लिए यह सबसे कम महत्वपूर्ण और कम से कम इस्तेमाल किया जाने वाला हिस्सा है।

कार्यात्मक प्रोग्रामिंग के सबसे उपयोगी भाग अपरिवर्तनीयता (चर के बजाय टोकन / मूल्य), फ़ंक्शन (कोई साइड इफेक्ट नहीं), और बंद होते हैं।

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