🤷🏼 💇🏾 🧢 क्यों एक युगल और एक टुपल अक्सर खराब होते हैं 🙎🏾 🧝🏼 🧐

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

pair <int, double> p1 ( 10, 1.1e-2 ); pair <int, double> p2 = make_pair ( 10, 2.22e-1 ); cout << "The pair p1 is: ( " << p1.first << ", " << p1.second << " )." << endl; cout << "The pair p2 is: ( " << p2.first << ", " << p2.second << " )." << endl;

सबसे पहले, विचार आकर्षक लगता है, क्योंकि:

एक फ़ंक्शन के लिए एक ही आयाम के कई वैक्टर पास करने के बजाय, आप उनके पत्राचार की जाँच के बारे में चिंता किए बिना, जोड़े \ tuples के केवल एक वेक्टर पास कर सकते हैं।
आप एक फ़ंक्शन से मानों का एक सेट आसानी से वापस ले सकते हैं बिना संकेत या बाहर मापदंडों के लिंक के साथ खुद को बेवकूफ बनाने के लिए (कई के लिए, यह मुश्किल है)
आप 2-3 फ़ील्ड की छोटी संरचनाओं का एक गुच्छा बनाने से बच सकते हैं (कम कोड बेहतर है)।

लेकिन इस बल का एक स्याह पक्ष है।

जैसा कि कहा जाता है, सादगी चोरी से भी बदतर है। जोड़े और tuples सिर्फ यही मामला है। वे वास्तव में ऊपर वर्णित सभी लाभ प्रदान करते हैं। लेकिन आइए कीमत के बारे में सोचते हैं।

एक जोड़ी या टपल की सामग्री एक रहस्य है

आइए देखें ऐसे समारोह की घोषणा:

 pair<string, string> GetInfo( int personId );

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

 struct Person { string Name; string Surname; } Person GetInfo( int personId );

सब कुछ क्रिस्टल स्पष्ट है, वापसी मूल्य को समझने के लिए फ़ंक्शन कोड को पढ़ने की कोई आवश्यकता नहीं है।

एक जोड़ी या टपल में डेटा का क्रम एक रहस्य है

ठीक है, हमने पिछले उदाहरण के बारे में बहुत कुछ सोचा और इस तरह से अपने कार्य को फिर से लिखा:

 pair<string, string> GetNameAndSurname( int personId );

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

गरीब की व्यापकता

हम आगे बढ़ते हैं - यदि हम अपने कार्य में और अधिक डेटा जोड़ना चाहते हैं तो क्या होगा? हां, हम एक जोड़ी को टूप्ले से बदल सकते हैं और इसे एक बेतुके आकार में बढ़ा सकते हैं:

 tuple<string, string, int> GetNameAndSurnameAndBirthday( int personId );

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

मूल्यों में से एक की अनुपस्थिति को दिखाने में असमर्थता

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

सत्यापन जाँच सम्मिलित करने के लिए कहीं नहीं

आइए इस फ़ंक्शन को देखें जो किसी डिवाइस के ऑपरेटिंग तापमान रेंज को लौटाता है:

 pair<int, int> SomeDevice::GetCelsiusTemperatureRange() { ... return make_pair( -300, +30 ); }

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

 struct TemperatureRange { int minTemp; int maxTemp; TemperatureRange( int min, int max ) { assert( min <= max ); assert( min >= -273 ); minTemp = min; maxTemp = max; } } TemperatureRange SomeDevice::GetCelsiusTemperatureRange() { ... return TemperatureRange( -300, +30 ); //   assert! }

counterexample

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

 pair<int, int> GetTwoRandomNumbers();

यह सुविधा खराब क्यों नहीं है? सब कुछ बहुत सरल है:

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

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

निष्कर्ष

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

क्यों एक युगल और एक टुपल अक्सर खराब होते हैं