सार्वजनिक विधि से हैशटेबल को वापस करने में क्या गलत है और ऐसा करने के लिए कब समझ में आता है?


9

सार्वजनिक पद्धति से हैशटेबल वापस करने में डिज़ाइन की समस्याएँ क्या होती हैं, जब आप एक क्लास बनाने के बजाय कई आइटम वापस करना चाहते हैं और उस वस्तु को वापस करना चाहते हैं?

अगर इसमें समस्याएँ हैं तो किन परिस्थितियों में ऐसा करना समझ में आता है?

भाषा के गतिशील होने या न होने के आधार पर इस प्रश्न का उत्तर कैसे बदलता है?

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

जवाबों:


11

हैशटेबल की तुलना में एक बेहतर परिभाषित वर्ग का उपयोग करें जो हैशटेबल की तुलना में है जो मान / नाम जोड़े के रूप में मूल्यों की मनमानी संख्या रखता है।

  1. पहला और पहला सबसे महत्वपूर्ण बिंदु है - रखरखाव। कोड को देखकर, एक नया प्रोग्रामर यह कभी नहीं कह सकता कि वे कौन से मूल्य हैं जो विधि वापस आ रही है। यदि कोई नया व्यक्ति कोड को देखकर इसे नहीं समझता है, तो कोड उपयोगी नहीं होगा और त्रुटियों के लिए प्रवण होगा जब भी कोई व्यक्ति उस डेटा में अधिक कुंजी / मान जोड़ने या एप्लिकेशन को बढ़ाने जा रहा है।

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

  3. HashMap<String,String>यदि आप रिटर्न स्टेटमेंट में नंबर (आयु कहना) जोड़ना चाहते हैं तो आप इस तरह से जेनेरिक का उपयोग नहीं कर सकते । यदि आप जेनरिक का उपयोग नहीं करते हैं, तो आपको वास्तविक प्रकार के ऑब्जेक्ट के बीच आगे और पीछे डालना होगा। यदि आप डायनेमिक टाइपिंग का उपयोग करते हैं तो आप इसे बचा सकते हैं।

  4. साथ ही संकलन समय में मुद्दों को पकड़ने की तुलना में रनटाइम विफलता की अधिक संभावना है। उदाहरण के लिए, अगर किसी ने हैशमैप से एक प्रविष्टि को हटा दिया है और पुराने कॉलर्स में से एक प्रविष्टि की उम्मीद कर रहा है, क्लाइंट रनटाइम के दौरान विफल रहता है। संकलन समय में इस मुद्दे को पकड़ना हमेशा बेहतर होता है।

  5. एक अपरिवर्तनीय प्रकार को वापस करना मुश्किल होगा यदि आप हैशमैप का उपयोग रिटर्न प्रकार और इतने पर करना चाहते हैं। लेकिन अगर आप अपने प्रकार से परिभाषित उपयोगकर्ता का उपयोग करते हैं, तो आप इसे नियंत्रित कर सकते हैं।

यह हैशमैप को रिटर्न प्रकार के रूप में उपयोग करने के लिए आकर्षक होगा क्योंकि आप शुरुआत में कुछ कक्षाएं बनाने से बच सकते हैं लेकिन भविष्य में कोड को बनाए रखने के लिए यह एक बुरा सपना होगा। गो ऑब्जेक्ट ओरिएंटेड !!!!


1
लगता है आपने प्रश्न को सही ढंग से समझा है। धन्यवाद।
मुहम्मद हसन खान

8

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

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

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

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

संपादित करें - जब आप गतिशील भाषाओं के बारे में बात कर रहे हों, तो इस उत्तर में उठाए गए अधिकांश बिंदु लागू होते हैं :)


यदि भाषा गतिशील है तो क्या होगा?
मुहम्मद हसन खान

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

3
@ हसन खान: उस मामले में वास्तव में हैशटेबल और क्लास उदाहरण के बीच कोई अंतर नहीं हो सकता है। उदाहरण के लिए, जावास्क्रिप्ट में सभी वस्तुओं को कर रहे हैं hashtables, और object.property वास्तव में वस्तु के रूप में एक ही बात है [ 'संपत्ति']
माइकल Borgwardt

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

7

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

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

संपादित करें :

स्पष्ट करने के लिए, मैं यहां शब्दकोश शब्द का उपयोग कर रहा हूं, जिसका अर्थ है कि यहां डेटा-संरचना का सबसे सामान्य प्रकार; मेरा मतलब किसी भी भाषा-विशिष्ट कार्यान्वयन जैसे कि पायथन dictया .NET का नहीं है Dictionary


1
+1 के लिए "यह नीचे आता है कि क्या आप कुंजी को डेटा का हिस्सा मानते हैं, या कोड का हिस्सा।" - यह एक अच्छा तरीका है। उदाहरण के लिए 'मानचित्र' के विपरीत 'शब्दकोश' शब्द कितना सार्वभौमिक है, यह निश्चित नहीं है।
मत्तीदेवी

शब्दकोश लौटाना उद्देश्य नहीं था। कुंजियाँ डेटा का नहीं कोड का हिस्सा थीं।
मुहम्मद हसन खान

असली सवाल 'आप एक उचित प्रकार का निर्माण होना चाहिए' के ​​पीछे तर्क है। सवाल है क्यों?
मुहम्मद हसन खान

2

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


वास्तव में आपकी सलाह सही है लेकिन सवाल यह है कि हैशटेबल का उपयोग करने के लिए चुना जाना गलत है जब कक्षा एक बेहतर विकल्प है।
मुहम्मद हसन खान

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