एफपी बनाम ओओपी

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

पिछले कुछ वर्षों में, मैं बार-बार कार्यात्मक प्रोग्रामिंग का अध्ययन करने वाले लोगों के साथ मिलकर कार्यक्रम करने में सक्षम रहा हूं जो ओओपी के बारे में पक्षपाती थे। यह आमतौर पर बयानों के रूप में व्यक्त किया गया था: "ठीक है, यह बहुत कुछ वस्तु की तरह है।"

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

जब हम एक नई तकनीक लेते हैं, तो हम अक्सर उन पुरानी तकनीकों से बचना शुरू कर देते हैं, जिन्हें हमने पहले इस्तेमाल किया था। यह स्वाभाविक है, क्योंकि हम मानते हैं कि नई तकनीक "बेहतर" है और इसलिए पुरानी तकनीक शायद "बदतर" है।

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

OOP क्या है?

मैं एक कमीवादी दृष्टिकोण से इस मुद्दे पर संपर्क करूंगा। OOP की कई सही परिभाषाएँ हैं जो कई अवधारणाओं, सिद्धांतों, तकनीकों, पैटर्न और दर्शन को कवर करती हैं। मैं उन्हें नजरअंदाज करने और खुद नमक पर ध्यान केंद्रित करने का इरादा रखता हूं। यहां, कटौतीवाद की आवश्यकता है क्योंकि OOP के आसपास के अवसरों का यह सारा धन वास्तव में OOP के लिए कुछ खास नहीं है; यह सामान्य रूप से सॉफ्टवेयर विकास में पाए गए अवसरों के धन का एक हिस्सा है। यहां मैं ओओपी के हिस्से पर ध्यान केंद्रित करूंगा, जो कि परिभाषित और अचूक है।

दो भाव देखें:

1: एफ (ओ); 2: का ();

अंतर क्या है?

स्पष्ट रूप से कोई शब्दार्थ अंतर नहीं है। पूरा अंतर पूरी तरह से वाक्य रचना में है। लेकिन एक प्रक्रियात्मक दिखता है, और दूसरा वस्तु उन्मुख है। इसका कारण यह है कि हम इस तथ्य के अभ्यस्त हैं कि अभिव्यक्ति 2 के लिए। विशेष रूप से एक विशेष व्यवहार शब्दार्थ का अर्थ है कि अभिव्यक्ति 1 नहीं है। यह विशेष व्यवहार शब्दार्थ बहुरूपता है।

जब हम अभिव्यक्ति 1 देखते हैं। हम फ़ंक्शन को देखते हैं, जिसे ऑब्जेक्ट ओ कहा जाता है । इसका तात्पर्य यह है कि केवल एक फ़ंक्शन है जिसका नाम f है, और इस तथ्य से नहीं कि यह ओ के आसपास के कार्यों के मानक कोहोर्ट का सदस्य है।

दूसरी ओर, जब हम अभिव्यक्ति 2 देखते हैं। हम ओ नाम के साथ एक वस्तु देखते हैं, जिसमें f नाम के साथ एक संदेश भेजा जाता है। हम उम्मीद करते हैं कि संदेश प्राप्त करने वाले अन्य प्रकार के ऑब्जेक्ट हो सकते हैं, और इसलिए हम नहीं जानते हैं कि कॉल के बाद एफ से क्या विशिष्ट व्यवहार की उम्मीद है। व्यवहार प्रकार ओ पर निर्भर करता है। यह है, एफ बहुरूपी है।

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

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

इसलिए, जो वास्तव में ओओपी कार्यक्रमों को गैर-ओओपी कार्यक्रमों से अलग करता है वह बहुरूपता है।

आप यह तर्क देना चाह सकते हैं कि पॉलीफोरिज्म केवल एफ स्विच के अंदर या लंबे समय तक / अन्य श्रृंखलाओं का उपयोग करके किया जा सकता है। यह सच है, इसलिए मुझे OOP के लिए एक और सीमा निर्धारित करने की आवश्यकता है।

बहुरूपता के उपयोग को कॉल करने वाले पर निर्भरता पैदा नहीं करनी चाहिए।

इसे समझाने के लिए, आइए फिर से भावों को देखें। अभिव्यक्ति 1: f (o) स्रोत कोड स्तर पर फ़ंक्शन f पर निर्भर करती है। हम यह निष्कर्ष निकालते हैं क्योंकि हम यह भी मानते हैं कि एफ केवल एक है और इसलिए कॉल करने वाले को कैली के बारे में पता होना चाहिए।

हालाँकि, जब हम एक्सप्रेशन 2 की () को देखते हैं तो हम कुछ और मान लेते हैं। हम जानते हैं कि च के कई अहसास हो सकते हैं और हमें नहीं पता कि इनमें से कौन सा कार्य वास्तव में कहा जाएगा। इसलिए, अभिव्यक्ति 2 युक्त स्रोत कोड फ़ंक्शन से स्वतंत्र है जिसे स्रोत कोड स्तर पर बुलाया जा रहा है।

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

तो, OOP की हमारी न्यूनतावादी परिभाषा है:

एक तकनीक जो कॉल करने के लिए गतिशील बहुरूपता का उपयोग करती है और स्रोत कोड स्तर पर कॉल करने वाले पर निर्भरता पैदा नहीं करती है।

वायुसेना क्या है?

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

f (a) == f (b) यदि a == b।

एक कार्यात्मक कार्यक्रम में, एक ही तर्क के साथ एक फ़ंक्शन को कॉल करना एक ही परिणाम देता है, भले ही कार्यक्रम कितने समय से चल रहा हो। इसे कभी-कभी संदर्भित पारदर्शिता कहा जाता है।

यह ऊपर से इस प्रकार है कि एफ को वैश्विक राज्य के उन हिस्सों को नहीं बदलना चाहिए जो एफ के व्यवहार को प्रभावित करते हैं। इसके अलावा, अगर हम कहते हैं कि f सिस्टम के सभी कार्यों का प्रतिनिधित्व करता है - अर्थात, सिस्टम के सभी कार्य संदर्भित रूप से पारदर्शी होने चाहिए - तो सिस्टम में कोई भी फ़ंक्शन वैश्विक स्थिति को नहीं बदल सकता है। कोई भी कार्य कुछ भी नहीं कर सकता है जो सिस्टम से दूसरे फ़ंक्शन को एक ही तर्क के साथ एक अलग मान लौटा सकता है।

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

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

बेशक, ध्यान पुनरावृत्ति में है। एक फ़ंक्शन पर विचार करें जो एक तर्क के रूप में राज्य के साथ एक संरचना लेता है। इस तर्क में सभी राज्य सूचनाएँ होती हैं जिन्हें किसी फ़ंक्शन को कार्य करना होता है। जब काम समाप्त हो जाता है, तो फ़ंक्शन एक ऐसी स्थिति के साथ एक नई संरचना बनाता है जिसकी सामग्री पिछले एक से अलग होती है। और अंतिम क्रिया के साथ, फ़ंक्शन खुद को एक तर्क के रूप में एक नई संरचना के साथ कहता है।

यह केवल उन सरल ट्रिक्स में से एक है जो एक कार्यात्मक कार्यक्रम राज्य परिवर्तन [1] को बदलने के बिना राज्य परिवर्तनों को संग्रहीत करने के लिए उपयोग कर सकता है।

तो, कार्यात्मक प्रोग्रामिंग की न्यूनतावादी परिभाषा:

रेफ़रेंशियल ट्रांसपेरेंसी - आप मूल्यों को पुन: असाइन नहीं कर सकते।

एफपी बनाम ओओपी

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

यह स्पष्ट है कि मैंने जो दो कटौतीवादी परिभाषाएँ चुनी हैं, वे पूरी तरह से ऑर्थोगोनल हैं। बहुरूपता और सम्मानजनक पारदर्शिता का एक दूसरे से कोई लेना-देना नहीं है। वे किसी भी तरह से प्रतिच्छेद नहीं करते हैं।

लेकिन रूढ़िवादिता आपसी बहिष्कार का मतलब नहीं है (जेम्स क्लर्क मैक्सवेल से पूछें)। एक ऐसी प्रणाली बनाना पूरी तरह से संभव है जो गतिशील बहुरूपता और संदर्भात्मक पारदर्शिता दोनों का उपयोग करता है। यह केवल संभव नहीं है, यह सही और अच्छा है!

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

रेफ़रेंशियल ट्रांसपेरेंसी पर बने सिस्टम भी अच्छे हैं क्योंकि वे प्रेडिक्टेबल हैं। राज्य अपरिवर्तनीयता ऐसी प्रणालियों को समझने, बदलने और सुधारने में आसान बनाती है। यह दौड़ और अन्य बहुस्तरीय मुद्दों की संभावना को बहुत कम करता है।

यहाँ मुख्य विचार यह है:

कोई होलीवर एफपी बनाम ओओपी नहीं है

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

[१] चूंकि हम वॉन न्यूमैन वास्तुकला के साथ मशीनों का उपयोग करते हैं, हम मानते हैं कि उनके पास मेमोरी सेल हैं जिनकी स्थिति वास्तव में बदलती है। मेरे द्वारा वर्णित पुनरावर्तन तंत्र में, पूंछ पूंछ पुनरावृत्ति अनुकूलन नए ग्लास फ्रेम के निर्माण की अनुमति नहीं देगा और मूल ग्लास फ्रेम का उपयोग किया जाएगा। लेकिन संदर्भात्मक पारदर्शिता (आमतौर पर) का यह उल्लंघन प्रोग्रामर से छिपा हुआ है और कुछ भी प्रभावित नहीं करता है।