अनुवाद: OOP प्रोग्रामर के लिए भी FI महत्वपूर्ण क्यों है?

नमस्कार, हेब्र! मैं आपके लिए रोमन प्रोवाज़निक के एक लेख का अनुवाद प्रस्तुत करता हूं - क्यों ओपी डेवलपर के लिए भी एफपी मायने रखता है?

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

मुझे उद्देश्यपूर्ण उन्मुख दृष्टिकोण से कार्यात्मक प्रोग्रामिंग पर एक व्यक्तिगत राय देने के लिए कहा गया था। मैं भी माध्यम पर एक खाता बनाने के लिए मजबूर किया गया था। एक पूर्व OOP डेवलपर के रूप में और किसी दिन, मैं एक वास्तविक FP प्रोग्रामर बन जाऊंगा, मुझे लगता है कि मुझे कुछ कहना है:

आपका स्वागत है यात्री

यदि आपने पिछले 60 वर्षों को किसी अन्य ग्रह पर नहीं बिताया है (यदि हां, तो आपका स्वागत है, यात्री), आपने संभवतः कार्यात्मक प्रोग्रामिंग के बारे में सुना है। यदि आप सॉफ़्टवेयर उद्योग में वर्तमान रुझानों का पालन करते हैं, तो आप "कार्यात्मक प्रोग्रामिंग", "अपरिवर्तनीयता", "शुद्ध कार्य" और "रचना" जैसे शब्द रोज़ सुनते हैं। जब तक आपको लगता है कि यह सब शांत, आनंदमय और समझ में आता है: “अरे, मैं एक OOP प्रोग्रामर हूं और मैं प्रतिमान को नहीं बदल सकता (या नहीं चाहता)। कार्यात्मक प्रोग्रामिंग मुझे क्या दे सकता है? मुझे क्यों परेशान होना चाहिए? ” एफपी प्रोग्रामर / उत्साही के रूप में जो ओओपी दुनिया से आया था, मैं वह साझा करना चाहता हूं जो मैं खुद कई वर्षों पहले जानना चाहता हूं। आप इसके बारे में घंटों बात कर सकते हैं, तो चलिए तीन सबसे महत्वपूर्ण चीजों को चुनते हैं।

अचलता

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

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

शुद्ध कार्य

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

एक बार फिर, I / O दृष्टिकोण के थोड़ा पुनर्विचार करने से एफपी के सभी फायदे मिलते हैं, साथ ही परीक्षण इतना सरल हो जाता है कि यह अंत में खुशी लाने लगेगा।

घोषणात्मक वीएस इम्पीरेटिव

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

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

सारांश

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