कार्यात्मक प्रोग्रामिंग और OOP के बारे में बहस करना बंद करें

पोस्ट में एक निश्चित मात्रा में भोज होता है, स्वास्थ्य मंत्रालय एक अप्रस्तुत पाठक को पढ़ने से मना करने के लिए कहता है।

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

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

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

और अब दो सवाल:
- क्या हम OOP में शुद्ध कार्यों का उपयोग कर सकते हैं?
- क्या हम FP में डेटा के लिए कार्यों को बांध सकते हैं?
दोनों का जवाब हां में है। स्टैटिक क्लास के तरीके शुद्ध हो सकते हैं, यहां तक ​​कि उदाहरण के तरीकों को साफ माना जा सकता है यदि वे साइड इफेक्ट्स नहीं बनाते हैं और हम पैरामीटर पर क्लास इंस्टेंस के गुणों पर विचार करते हैं। शास्त्रीय परिभाषाओं की सीमाओं को फुलाया जाता है और कुछ असहमत हो सकते हैं, लेकिन व्यवहार में यह सिर्फ काम करता है। और इस तरह के तरीकों को औपचारिक रूप से परीक्षण किया जाता है और सभी तोपों के अनुसार लिखे गए शुद्ध शुद्ध कार्यों से बदतर नहीं होता है। डेटा के लिए बाध्यकारी तरीकों के बारे में थोड़ा अधिक जटिल है, भाषा और पुस्तकालयों ने प्रतिबंधों का इस्तेमाल किया। मान लीजिए कि यह जावास्क्रिप्ट में किया गया है, हास्केल और एर्लैंग के बारे में निश्चित नहीं है। अब सबसे दिलचस्प बात यह है कि यह क्या देता है, और क्यों ओओपी ने 20-30 साल पहले इस तरह का प्रचार किया है। यदि आप एक छोटा सा कार्यक्रम लिखते हैं - आप अपनी इच्छानुसार लिख सकते हैं, तो सौंदर्य की भावना को छोड़कर यह कुछ भी प्रभावित नहीं करता है। जब आप वास्तव में एक बड़ा कार्यक्रम बनाते हैं, तो जटिलता की समस्या उत्पन्न होती है। कम्प्यूटेशनल जटिलता का नहीं, हम मानते हैं कि यहां हम सब कुछ अच्छा कर रहे हैं, लेकिन कथित जटिलता का। मान लें कि आपके पास कोड की 50,000 लाइनें हैं, और उनमें से सभी उपयोगी हैं। उन्हें कैसे व्यवस्थित किया जाए ताकि वे पागल न हों (या 11 रातों को काम न छोड़ें)? हम संचालन की संख्या को कम नहीं कर सकते हैं, लेकिन हम उनके बीच कनेक्शन की संख्या को कम कर सकते हैं (इनकैप्सुलेशन हमें इसके साथ मदद करता है)। हम एक सरल इंटरफ़ेस के पीछे जटिल कार्यान्वयन को छिपाते हैं और केवल इंटरफ़ेस के साथ काम करना जारी रखते हैं। उदाहरण के लिए, इंटरनेट एक बहुत जटिल बात है, लेकिन अधिकांश डेवलपर्स को अपना काम करने के लिए HTTP प्रोटोकॉल का पर्याप्त ज्ञान है और नेटवर्क, भौतिक और अन्य स्तरों को सिस्टम प्रशासक पर छोड़ देता है । हमारे मॉड्यूल की कनेक्टिविटी कमजोर है, एक दूसरे के साथ उनके एकीकरण के चरण में कम जटिलता । कम एक मॉड्यूल दूसरे के बारे में जानता है, जितना कम वे जुड़े हुए हैं। मॉड्यूल के अंदर डेटा को बांधने के तरीके हमें मॉड्यूल के उपभोक्ताओं से इस ज्ञान से छुटकारा पाने में मदद करते हैं। यह OOP का मुख्य व्यावहारिक लाभ है। किस पर? डेटा और विधि बंधन के बिना ऊपर दृष्टिकोण। एफपी, जैसा कि हमें पता चला है, इस बारे में कुछ नहीं कहता है। आप कक्षाओं को शुद्ध कार्यों के तर्क के रूप में पारित कर सकते हैं, या आप कक्षा के तरीकों के रूप में शुद्ध कार्यों का उपयोग कर सकते हैं, यह एक दूसरे के विपरीत नहीं है, लेकिन केवल इसे पूरक करता है।

व्यवहार में, जहां मुख्य रूप से एक दृष्टिकोण काम करता है, और दूसरा मुख्य रूप से कहां है? जब मैं NodeJS पर एक बैकएंड लिखता हूं, तो यह किसी भी तरह एक कार्यात्मक प्रतिमान में बदल जाता है। क्यों? क्योंकि सर्वर का अनुरोध इसकी प्रकृति द्वारा एक निश्चित इनपुट और आउटपुट के साथ एक फ़ंक्शन है। कार्यात्मक दृष्टिकोण सर्वर अनुरोधों पर बहुत स्वाभाविक रूप से गिरता है और कोड अधिक कॉम्पैक्ट और लचीला होता है। जब मैं ब्राउज़र के लिए एक दृश्यपटल बनाता हूं, तो ओओपी आमतौर पर बेहतर काम करता है, क्योंकि इनपुट और आउटपुट के अलावा, हमारे पास उपयोगकर्ता घटनाओं की एक धारा भी है, साथ ही साथ कार्यक्रम की घटनाओं, जैसे एनिमेशन और सर्वर अनुरोध आदि की शुरुआत और अंत में ... कार्यात्मक कार्य किया है। अगर यह सिर्फ अंतःक्रियात्मकता के बिना एक स्थिर पृष्ठ खींचने के लिए था, तो सामने के अंत में एफपी का उपयोग करते समय, या तो इंटरैक्टिव या विकास समय ग्रस्त होता है (हमारे माप के अनुसार, हर 3 बार)। क्यों?

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