क्यों "कार्यों और डेटा के बीच तंग युग्मन" खराब है?


38

मुझे यह उद्धरण " द जॉय ऑफ क्लोजर " में मिला । 32, लेकिन किसी ने पिछले हफ्ते रात के खाने पर मुझसे एक ही बात कही और मैंने इसे अन्य स्थानों पर भी सुना है:

[A] ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए नकारात्मक, फ़ंक्शन और डेटा के बीच का युग्मन है।

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

मेरा मतलब है, किसी फंक्शन को क्लास में जोड़ना ऐसा लगता है जैसे जीमेल में किसी मेल को टैग करना या किसी फाइल को फोल्डर में चिपका देना। यह एक संगठनात्मक तकनीक है जो आपको इसे फिर से खोजने में मदद करती है। आप कुछ मापदंड चुनते हैं, फिर चीजों को एक साथ रखते हैं। OOP से पहले, हमारे प्रोग्राम फाइलों में बहुत बड़े बैग थे। मेरा मतलब है, आपको कहीं न कहीं फंक्शन लगाने होंगे। उन्हें व्यवस्थित क्यों नहीं किया?

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

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

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

पुनश्च यह उद्धरण एक पुस्तक का संदर्भ देता है जिसे मैंने नहीं पढ़ा है: लेडा में मल्टीपरडीग्म प्रोग्रामिंग: टिमोथी बुद्ध, 1995


20
मेरा मानना ​​है कि लेखक ने ओओपी को ठीक से नहीं समझा और सिर्फ यह कहने के लिए एक और कारण की आवश्यकता थी कि जावा खराब है और क्लोजर अच्छा है। / शेख़ी
व्योम

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

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

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

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

जवाबों:


34

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

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

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

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


13

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

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

यह OO का नकारात्मक पहलू है - यह इस तरह की बुराई को प्रोत्साहित करता है, क्लोजर स्टैंडर्ड ( प्रोग्रामिंग की एक टूटी हुई खिड़की के सिद्धांत का एक प्रकार) बनाने के माध्यम से कार्य करने के लिए डेटा का युग्मन करता है ।

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


8
दिन का उद्धरण: "कुछ बुराई अक्सर काम पूरा करने के लिए आवश्यक होती है"
ग्लेनपेटर्सन

5
आपने वास्तव में यह नहीं बताया है कि जिन चीजों को आप बुराई कहते हैं, वे बुराई क्यों हैं; आप उन्हें केवल बुराई कह रहे हैं। समझाएं कि वे दुष्ट क्यों हैं, और आपके पास सज्जन के प्रश्न का उत्तर हो सकता है।
रॉबर्ट हार्वे

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

यदि OO और क्लोजर पर्यायवाची हैं, तो उनके लिए स्पष्ट समर्थन प्रदान करने में OO की कई भाषाएँ विफल क्यों रही हैं? आपके द्वारा उद्धृत C2 विकी पृष्ठ में उस साइट के लिए सामान्य से अधिक विवाद (और कम आम सहमति) है।
इसका

1
@itsbruce वे काफी हद तक अनावश्यक हैं। चर जो "बंद ओवर" के बजाय कक्षा चर वस्तु में पारित हो जाएगा।
इज़काता

7

यह प्रकार युग्मन के बारे में है :

उस वस्तु पर काम करने के लिए बनाई गई एक फ़ंक्शन का उपयोग अन्य प्रकार की वस्तुओं पर नहीं किया जा सकता है।

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

फ्री-स्टैंडिंग फ़ंक्शंस ऐसी डिकूप्लिंग की अनुमति देते हैं जो आपको तब नहीं मिलती हैं जब आप टाइप ए के अंदर काम करने के लिए अपने कार्यों को लिखने पर ध्यान केंद्रित करते हैं क्योंकि तब आप उनका उपयोग नहीं कर सकते हैं यदि आपके पास टाइप ए नहीं है, भले ही फ़ंक्शन हो सकता है अन्यथा एक B उदाहरण या C C प्रकार पर उपयोग किए जाने के लिए पर्याप्त सामान्य है।


3
इंटरफेस की पूरी बात नहीं है? टाइप बी और टाइप सी को अपने कार्य को देखने की अनुमति देने वाली चीजें प्रदान करने के लिए, इसलिए यह एक से अधिक प्रकारों पर काम कर सकता है?
रैंडम 832

2
@ रैंडम 832 बिल्कुल, लेकिन डेटा प्रकार के अंदर एक फ़ंक्शन एम्बेड क्यों करें यदि उस डेटा प्रकार के साथ काम नहीं करना है? उत्तर: किसी फ़ंक्शन को डेटा प्रकार में एम्बेड करने का एकमात्र कारण है । आप स्थैतिक कक्षाओं के अलावा कुछ भी नहीं लिख सकते हैं और अपने सभी कार्यों को उन डेटा प्रकारों के बारे में परवाह नहीं करते हैं जिन्हें वे अपने स्वयं के प्रकार से पूरी तरह से डिकॉउप करने के लिए एनकैप्सुलेटेड हैं, लेकिन फिर भी उन्हें एक प्रकार में डालने से क्यों परेशान हैं? कार्यात्मक दृष्टिकोण कहता है: परेशान मत करो, अपने कार्यों को इंटरफेस के प्रकारों के लिए काम करने के लिए लिखें, और फिर उन्हें अपने डेटा के साथ एनकैप्सुलेट करने का कोई कारण नहीं है।
जिमी होफा

आपको अभी भी इंटरफेस को लागू करना है।
198 में रैंडम 832

2
@ Random832 इंटरफेस डेटा प्रकार हैं; उन्हें किसी भी प्रकार के कार्यों की आवश्यकता नहीं है। नि: शुल्क कार्यों के साथ, सभी इंटरफेस को बाहर निकालने की आवश्यकता होती है जो वे काम करने के लिए कार्यों के लिए उपलब्ध डेटा बनाते हैं।
जिमी हॉफ

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

4

जावा और OOP के समान अवतारों में, उदाहरण के तरीके (मुफ्त कार्यों या विस्तार विधियों के विपरीत) को अन्य मॉड्यूल से नहीं जोड़ा जा सकता है।

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


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

1
@ JörgWMittag मुझे लगता है कि आपका मतलब बीजगणित डेटाैटिप्स था। और कोडइन्चोस, हास्केल बहुत स्पष्ट रूप से आपके सुझाव को हतोत्साहित करता है। इसे अनाथ उदाहरण कहा जाता है और जीएचसी पर चेतावनी जारी करता है।
जोजफग

3
@ JörgWMittag मेरी धारणा यह है कि OOP की आलोचना करने वाले कई लोग जावा में प्रयुक्त OOP के रूप की आलोचना करते हैं और इसी तरह की भाषाओं में इसकी कठोर वर्ग संरचना और उदाहरण के तरीकों पर ध्यान केंद्रित करते हैं। उस उद्धरण की मेरी धारणा यह है कि यह उदाहरण के तरीकों पर ध्यान केंद्रित करने की आलोचना करता है और वास्तव में OOP के अन्य स्वादों पर लागू नहीं होता है, जैसे कि gangang उपयोग करता है।
कोडइन्चौस

2
@CodesInChaos तो शायद इसे "स्थिर वर्ग आधारित OO" के रूप में स्पष्ट कर रहा है
jozefg

@jozefg: मैं सार डेटा प्रकारों के बारे में बात कर रहा हूँ। मैं यह भी नहीं देखता कि कैसे बीजगणितीय डेटा प्रकार इस चर्चा के लिए दूरस्थ रूप से प्रासंगिक हैं।
जोर्ग डब्ल्यू मित्तग

3

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

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

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

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


मेरे पास OOP में कक्षाएं हैं जो परिस्थितियों के आधार पर आंतरिक डेटा संरचनाओं को स्विच करती हैं इसलिए इन वर्गों के ऑब्जेक्ट इंस्टेंस एक ही समय में बहुत भिन्न डेटा प्रतिनिधित्व का उपयोग कर सकते हैं। बेसिक डेटा छुपा और encapsulation मैं कहूँगा? तो स्काला में मैप एक ओओपी भाषा में सही तरीके से लागू (wrt data hiding और encapsulation) मैप क्लास से कैसे अलग है?
मार्जन वेनेमा

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

2

डेटा और फ़ंक्शंस के बीच तंग युग्मन खराब है क्योंकि आप एक-दूसरे को स्वतंत्र रूप से बदलने में सक्षम होना चाहते हैं और तंग युग्मन यह कठिन बनाता है क्योंकि आप ज्ञान के बिना एक को नहीं बदल सकते हैं और संभवतः दूसरे को बदल सकते हैं।

आप फ़ंक्शन में प्रस्तुत किए गए विभिन्न डेटा को फ़ंक्शन में किसी भी बदलाव की आवश्यकता नहीं है और इसी तरह आप उन फ़ंक्शन परिवर्तनों का समर्थन करने के लिए चल रहे डेटा में किसी भी परिवर्तन की आवश्यकता के बिना फ़ंक्शन में परिवर्तन करने में सक्षम होना चाहते हैं।


1
हां मुझे वह चाहिये। लेकिन मेरा अनुभव यह है कि जब आप एक गैर-तुच्छ फ़ंक्शन को डेटा भेजते हैं, जिसे स्पष्ट रूप से हैंडल करने के लिए डिज़ाइन नहीं किया गया था, तो वह फ़ंक्शन टूट जाता है। मैं केवल सुरक्षा टाइप करने की बात नहीं कर रहा हूं, बल्कि ऐसी कोई भी डेटा स्थिति जो फ़ंक्शन के लेखक (ओं) द्वारा अनुमानित नहीं थी। यदि फ़ंक्शन पुराना है और अक्सर उपयोग किया जाता है, तो कोई भी परिवर्तन जो नए डेटा को इसके माध्यम से प्रवाह करने की अनुमति देता है, कुछ पुराने डेटा के लिए इसे तोड़ने की संभावना है जो अभी भी काम करने की आवश्यकता है। जबकि डिकम्पलिंग कार्य बनाम डेटा के लिए आदर्श हो सकता है, उस डिकम्पलिंग की वास्तविकता कठिन और खतरनाक हो सकती है।
ग्लेनपेटर्सन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.