पूर्ण अपरिवर्तनीयता और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग


43

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

दोनों परिवर्तनशील और अपरिवर्तनीय वस्तुएं अपने स्वयं के फायदे और नुकसान की पूरी सूची लाती हैं।

ऐसी भाषाएं हैं जो उदाहरण के लिए दोनों तरह के स्कैला से शादी करने की कोशिश करती हैं, जहां आपके पास (स्पष्ट रूप से घोषित) परस्पर और अपरिवर्तनीय डेटा है (कृपया मुझे सही करें अगर मैं गलत हूं, तो स्कैला का मेरा ज्ञान सीमित से अधिक है)।

मेरा प्रश्न है: क्या पूर्ण (sic!) अपरिवर्तनीयता-किसी भी वस्तु को एक बार बनाए जाने के बाद उत्परिवर्तित नहीं कर सकती है- किसी ओओपी संदर्भ में कोई मतलब?

क्या ऐसे मॉडल के डिजाइन या कार्यान्वयन हैं?

मूल रूप से, (पूर्ण) अपरिवर्तनीयता और OOP विरोधी या रूढ़िवादी हैं?

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


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

4
Mutability C # और Java जैसी OOP भाषाओं की संपत्ति नहीं है और न ही अपरिवर्तनीयता है। आप जिस तरह से कक्षा लिखते हैं, उससे आप परिवर्तनशीलता या अपरिवर्तनीयता निर्दिष्ट करते हैं।
रॉबर्ट हार्वे

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

2
@ मिचेल्ट यह सवाल विशिष्ट चीजों को परिवर्तनशील बनाने के बारे में नहीं है, यह सभी चीजों को अपरिवर्तनीय बनाने के बारे में है।

जवाबों:


43

ओओपी और अपरिवर्तनीयता एक दूसरे के लिए लगभग पूरी तरह से रूढ़िवादी हैं। हालांकि, अनिवार्य प्रोग्रामिंग और अपरिवर्तनीयता नहीं है।

OOP को दो मुख्य विशेषताओं द्वारा संक्षेपित किया जा सकता है:

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

  • डायनेमिक डिस्पैच : जब मैं किसी ऑब्जेक्ट को एक विधि पर कॉल करता हूं, तो निष्पादित पद्धति को रन टाइम पर हल किया जाएगा। (जैसे कक्षा-आधारित ओओपी में, मैं उदाहरण के लिए एक sizeविधि कह सकता हूं IList, लेकिन कॉल को LinkedListकक्षा में कार्यान्वयन के लिए हल किया जा सकता है )। डायनामिक डिस्पैच एक तरीका है बहुरूपता व्यवहार की अनुमति देना।

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

एक अनिवार्य कार्यक्रम में कथनों को क्रमबद्ध तरीके से निष्पादित किया जाता है। एक बयान के कार्यक्रम की स्थिति को बदलने जैसे दुष्प्रभाव हैं। अपरिवर्तनीयता के साथ, राज्य को बदला नहीं जा सकता है (निश्चित रूप से, एक नया राज्य बनाया जा सकता है)। इसलिए, अपरिवर्तनीयता के साथ अनिवार्य प्रोग्रामिंग मौलिक रूप से असंगत है।

अब ऐसा होता है कि OOP ऐतिहासिक रूप से हमेशा अनिवार्य प्रोग्रामिंग के साथ जुड़ा हुआ है (Simula Algol पर आधारित है), और सभी मुख्यधारा OOP भाषाओं में अनिवार्य जड़ें (C ++, Java, C #,… सभी C में निहित हैं)। इसका अर्थ यह नहीं है कि ओओपी स्वयं अत्यावश्यक या परिवर्तनशील होगा, इसका मतलब यह है कि इन भाषाओं द्वारा ओओपी का कार्यान्वयन उत्परिवर्तन की अनुमति देता है।


2
विशेष रूप से दो मुख्य विशेषताओं की परिभाषा के लिए बहुत-बहुत धन्यवाद।
हाइपरबोरस

डायनेमिक डिस्पैच OOP की एक मुख्य विशेषता नहीं है। न तो वास्तव में एनकैप्सुलेशन है (जैसा कि आप पहले ही स्वीकार कर चुके हैं)।
मोनिका

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

2
"ऑब्जेक्ट्स विधियों और डेटा की एक जोड़ी है"। बस आपको कुछ ऐसी चीज़ों की ज़रूरत होती है जिनका अपरिचय से कोई लेना-देना नहीं है।
मोनिका

3
@CodeYogi डेटा छिपाना एनकैप्सुलेशन का सबसे आम प्रकार है। हालाँकि, डेटा को किसी ऑब्जेक्ट द्वारा आंतरिक रूप से संग्रहीत किया जाता है, केवल कार्यान्वयन विवरण नहीं है जिसे छिपाया जाना चाहिए। यह छिपाना भी उतना ही महत्वपूर्ण है कि सार्वजनिक इंटरफ़ेस कैसे लागू किया जाता है, जैसे कि मैं किसी सहायक विधि का उपयोग करता हूं या नहीं। ऐसे सहायक तरीके भी निजी होने चाहिए, आम तौर पर बोलना। इसलिए संक्षेप में: एनकैप्सुलेशन एक सिद्धांत है, जबकि डेटा छिपाना एक एनकैप्सुलेशन तकनीक है।
आमोन

25

ध्यान दें, ऑब्जेक्ट ओरिएंटेड प्रोग्रामर्स के बीच एक संस्कृति है , जहां लोग मान लेते हैं कि आप OOP कर रहे हैं, तो आपकी अधिकांश वस्तुएँ परस्पर मिल जाएंगी, लेकिन यह एक अलग मुद्दा है कि क्या OOP को परिवर्तनशीलता की आवश्यकता है । कार्यात्मक प्रोग्रामिंग के प्रति लोगों के जोखिम के कारण, संस्कृति धीरे-धीरे अधिक अपरिवर्तनीयता की ओर बदल रही है।

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

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

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


17

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

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

सभी कार्यात्मक भाषाओं को या तो अपरिवर्तनीयता की आवश्यकता नहीं होती है। क्लोजर में एक विशिष्ट एनोटेशन होता है जो प्रकारों को उत्परिवर्तित करने की अनुमति देता है, और अधिकांश "व्यावहारिक" कार्यात्मक भाषाओं में उत्परिवर्तित प्रकारों को निर्दिष्ट करने का एक तरीका है।

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


धन्यवाद। क्या आप अपने अंतिम पैराग्राफ को थोड़ा विस्तृत कर सकते हैं ("स्पष्ट" थोड़ा व्यक्तिपरक हो सकता है)।
हाइपरबोरस

पहले से ही किया ....
रॉबर्ट हार्वे

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

3
@RobertHarvey आप कहते हैं कि आपको परिवर्तनशीलता की आवश्यकता है क्योंकि आपको लूप की आवश्यकता है (अन्यथा आपको पुनरावृत्ति का उपयोग करना होगा)। इससे पहले कि मैंने दो साल पहले हास्केल का उपयोग करना शुरू किया, मुझे लगा कि मुझे भी परिवर्तनशील चर की आवश्यकता है। मैं सिर्फ यह कह रहा हूं कि "पाश" (मानचित्र, गुना, फिल्टर, आदि) के अन्य तरीके हैं। एक बार जब आप टेबल से लूपिंग कर लेते हैं, तो आपको अन्य परिवर्तनशील चर की आवश्यकता क्यों होगी?
साइमन

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

5

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

हालांकि यह संभव है कि परस्पर या अपरिवर्तनीय प्रकारों की वस्तुओं का उपयोग करते हुए एन्कैप्सुलेट मान का उपयोग किया जाए, एक वस्तु केवल एक मूल्य के रूप में व्यवहार कर सकती है यदि निम्न में से कम से कम एक स्थिति लागू होती है:

  1. वस्तु का कोई भी संदर्भ कभी भी उस चीज के संपर्क में नहीं आएगा जो राज्य को उसमें परिवर्तित हो सकता है।

  2. ऑब्जेक्ट के कम से कम एक संदर्भ के धारक को उन सभी उपयोगों के बारे में पता होता है जिनके लिए कोई भी अतिरिक्त संदर्भ डाला जा सकता है।

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

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

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


4

C # में कुछ प्रकार स्ट्रिंग की तरह अपरिवर्तनीय हैं।

इसके अलावा यह भी लगता है कि चुनाव का दृढ़ता से विचार किया गया है।

यह सुनिश्चित करने के लिए कि अपरिवर्तनीय प्रकारों का उपयोग करने की मांग करना वास्तव में प्रदर्शन है, यदि आपको उस प्रकार के हजार बार संशोधित करना है। यही कारण है कि इस मामले में StringBuilderकक्षा के बजाय कक्षा का उपयोग करने का सुझाव दिया गया है string

मैंने एक प्रोफाइलर के साथ एक प्रयोग किया है और अपरिवर्तनीय प्रकार का उपयोग करके वास्तव में अधिक सीपीयू और रैम की मांग है।

यह भी सहज है अगर आप समझते हैं कि 4000 वर्णों की एक स्ट्रिंग में केवल एक अक्षर को संशोधित करने के लिए आपको रैम के किसी अन्य क्षेत्र में हर चार को कॉपी करना होगा।


6
बार-बार बदलते डेटा के साथ अपरिवर्तनीय डेटा को संशोधित करने की आवश्यकता नहीं है string। लगभग सभी प्रकार के डेटा / उपयोग के मामलों के लिए, एक कुशल लगातार संरचना (अक्सर पहले से ही) का आविष्कार किया जा सकता है। उनमें से अधिकांश के पास लगभग समान प्रदर्शन हैं, भले ही स्थिर कारक कभी-कभी बदतर हों।

@delnan मुझे यह भी लगता है कि उत्तर के अंतिम पैराग्राफ के बारे में (im) उत्परिवर्तन की तुलना में एक कार्यान्वयन विवरण के बारे में अधिक है।
हाइपरबोरस

@ हाइपरबोरस: क्या आपको लगता है कि मुझे उस हिस्से को हटा देना चाहिए? लेकिन अपरिवर्तनीय होने पर एक स्ट्रिंग कैसे बदल सकती है? मेरा मतलब है .. मेरी राय में, लेकिन निश्चित रूप से मैं गलत हो सकता हूं, यही मुख्य कारण हो सकता है कि वस्तु अपरिवर्तनीय नहीं है।
प्रातः

1
@ स्पष्ट रूप से कोई मतलब नहीं है। इसे छोड़ दें, इसलिए यह चर्चा और अधिक दिलचस्प राय और दृष्टिकोण का कारण बनता है।
हाइपरबोरस

1
@ स्पष्ट, हां, पढ़ना धीमा होगा, हालांकि एक string(पारंपरिक प्रतिनिधित्व) को बदलने के रूप में धीमा नहीं है । 1000 मॉड्यूज़ के बाद एक "स्ट्रिंग" (जिस प्रतिनिधित्व के बारे में मैं बात कर रहा हूं) एक नए सिरे से बनाए गए स्ट्रिंग (मोडुलो कंटेंट) की तरह होगा; एक्स संचालन के बाद गुणवत्ता में कोई उपयोगी या व्यापक रूप से उपयोग किए जाने वाले लगातार डेटा संरचना में गिरावट नहीं होती है। मेमोरी विखंडन एक गंभीर समस्या नहीं है (आपके पास कई आवंटन होंगे, हाँ, लेकिन विखंडन आधुनिक कचरा संग्रहकर्ताओं में एक गैर-मुद्दा है)

0

हर चीज की पूर्ण अपरिवर्तनीयता OOP, या उस मामले के अधिकांश अन्य प्रतिमानों के लिए एक बहुत बड़ी वजह से बहुत मायने नहीं रखती है:

हर उपयोगी कार्यक्रम के दुष्प्रभाव होते हैं।

एक प्रोग्राम जो कुछ भी बदलने का कारण नहीं है, बेकार है। हो सकता है कि आपने इसे चलाया भी नहीं हो, क्योंकि प्रभाव समान होगा।

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

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


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

और एक भविष्य की स्थिति वर्तमान की जगह लेती है कि कैसे , बिल्कुल? एक OO कार्यक्रम में, वह राज्य किसी वस्तु का गुण है। राज्य को प्रतिस्थापित करने के लिए एक वस्तु को बदलने की आवश्यकता होती है (या इसे दूसरे के साथ प्रतिस्थापित करने की आवश्यकता होती है, जिसके लिए इसे संदर्भित करने वाली वस्तुओं में बदलाव की आवश्यकता होती है (या इसे दूसरे के साथ बदलना, जो ... एह आपको बिंदु मिलता है)। आप कुछ प्रकार के मोनैडिक हैक के साथ आ सकते हैं, जहां हर क्रिया एक नया आवेदन तैयार करती है ... लेकिन फिर भी, कार्यक्रम की वर्तमान स्थिति को कहीं न कहीं दर्ज करना होगा।
cHao

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

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


-2

मुझे लगता है कि यह इस पर निर्भर करता है कि ओओपी की आपकी परिभाषा यह है कि यह संदेश-गुजरने की शैली का उपयोग करता है।

शुद्ध कार्यों के लिए कुछ भी म्यूट नहीं करना पड़ता है क्योंकि वे उन मूल्यों को वापस करते हैं जिन्हें आप नए चर में स्टोर कर सकते हैं।

var brandNewVariable = pureFunction(foo);

मैसेज पासिंग स्टाइल के साथ, आप किसी ऑब्जेक्ट को यह पूछने के बजाय नए डेटा को स्टोर करने के लिए कहते हैं कि आपको नए वेरिएबल में कौन सा डेटा स्टोर करना चाहिए।

sameOldObject.changeMe(foo);

वस्तुओं को बाहर के बजाय ऑब्जेक्ट के अंदर रहने के लिए होने वाले शुद्ध कार्यों को बनाकर, ऑब्जेक्ट्स को म्यूट करना और उन्हें म्यूट करना संभव है।

var brandNewVariable = nonMutatingObject.askMe(foo);

लेकिन संदेश पासिंग स्टाइल और अपरिवर्तनीय वस्तुओं को मिलाना संभव नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.