हमें अधिमानतः प्रथम श्रेणी के संग्रह का उपयोग क्यों करना चाहिए?


15

द थॉटवर्क्स एंथोलॉजी में जेफ बे (आरटीएफ) द्वारा ऑब्जेक्ट कैलिसिथनिक्स के नियम नंबर 4 के अनुसार , यह अनुशंसा की जाती है कि किसी को " प्रथम श्रेणी के संग्रह का उपयोग करें "।

नियम 4: प्रथम श्रेणी के संग्रह

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

इससे जो मैं समझ सकता था, वह यह था कि हमें संग्रह को लपेटने और जोड़ने के तरीकों के साथ एक अलग वर्ग का उपयोग करना चाहिए, उस संग्रह के संशोधित डेटा को हटा देना चाहिए।

और हमें इसकी आवश्यकता है ताकि हम यह सुनिश्चित कर लें कि डेटाटाइप संग्रह में क्या जाता है और क्या निकलता है।

यदि हम सामान्य संग्रह का उपयोग करते हैं (उन भाषाओं में जहां यह लागू है), तो क्या हमें इस नियम का पालन करने की आवश्यकता है?

यदि मुझे एक महत्वपूर्ण महत्व याद आ रहा है, तो कृपया स्पष्ट करें।


1
अमोघ तलपलीकर ने नियम 8 को नियम 4 में बदल दिया है, क्योंकि नियम 8 वास्तव में "दो से अधिक आवृत्ति वाले कोई वर्ग नहीं है"।
यानिस

यह कहना लगता है सामग्री की तालिका में नियम 8 , और फिर इसे शरीर में नियम 4 कहा जाता है।
बेकार


6
क्या यह सिर्फ मेरे लिए है, या यह नियम संयुक्त राष्ट्र के कार्यान्वयन के रूप में लिखा गया है? मेरा मतलब है, आपको इसमें एक संग्रह के साथ एक वर्ग मिला है, इसलिए आप बाकी सब कुछ बाहर ले जाते हैं। अब आपकी कक्षा एक संग्रह है। इसलिए यदि आपने उस वर्ग के साथ एक और वर्ग प्राप्त किया है, तो उसमें एक संग्रह है, और ... लाठर, कुल्ला, दोहराना।
mjfgates

@mjfgates: हम्म ... ग्रेट पॉइंट! वास्तव में कुछ के बारे में सोचने के लिए!
अमोघ तलपल्लिकर

जवाबों:


12

प्रथम श्रेणी के संग्रह का उपयोग करने के लिए टाइप सुरक्षा एक बहुत ही मामूली कारण है। आपके लिंक से:

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

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

इस के लिए तर्क बहुत सरल है, संग्रह के आसपास पारित हो जाते हैं। जल्द ही, 4 अलग-अलग वर्गों की अपनी SearchByID()विधि है। या आपको जैसे रिटर्न वैल्यू मिलती हैMap<Integer, String> उस साथ है, जो उस नक्शे में संग्रहीत है जिसे छीन लिया गया है। प्रथम श्रेणी का संग्रह एक सरल समाधान है जिसकी लागत एक स्रोत फ़ाइल है। व्यवहार में, एक बार जब वे जगह में होते हैं (वे इकाई परीक्षणों को लिखने के लिए बहुत आसान होते हैं), संग्रह के साथ काम करने वाले किसी भी परिवर्तन को संभालना आसान होता है, जैसे कि जब SearchByIDइंट के बजाय GUID लेने की आवश्यकता होती है।


8

... संग्रह को लपेटने और जोड़ने के तरीकों के साथ एक अलग वर्ग का उपयोग करें, उस संग्रह का डेटा संशोधित करें

यह गारंटी की तुलना में बहुत अधिक है संग्रह में संग्रहीत वस्तुओं प्रकार की , हालांकि, यह किसी भी संग्रह के आक्रमणकारियों की गारंटी देता है।

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

एफडब्ल्यूआईडब्ल्यू, पाठ इस बारे में काफी स्पष्ट है (और मैं आपके प्रश्न में पूरी बात संपादित करूँगा, इसलिए किसी और को उस आरटीएफ को डाउनलोड करने की आवश्यकता नहीं है):

प्रत्येक संग्रह अपनी ही कक्षा में लिपट जाता है, इसलिए अब संग्रह से संबंधित व्यवहारों का एक घर है

प्रकार (या इसलिए जेनरिक) के साथ कुछ भी नहीं करना है, संग्रह के व्यवहार को डेटा के साथ जोड़ने के लिए सब कुछ करना है।


1

सरल उत्तर "नहीं" है यदि आप एक ऐसी भाषा का उपयोग कर रहे हैं जो जेनरिक का समर्थन करती है। क्योंकि टाइप के लिए जाँच करने की कोई आवश्यकता नहीं है क्योंकि भाषा की सुविधा स्वयं इस पर एक अच्छा काम करती है (मेरे जावा जेनरिक अनुभव से)।

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


मैं भी इसी तरह की पंक्तियों में सोच रहा हूं। लेकिन कुछ होना चाहिए, मैंने इसके लिए जो उदाहरण देखे, वे जावा और सी # में थे और दोनों सामान्य संग्रह का समर्थन करते हैं।
बजे अमोघ तलपलीकर

@AmoghTalpallikar: मेरा कहना था कि इसे सरल रखना है। जब तक मुझे डेटा संरचना के किसी विशिष्ट व्यवहार को ओवरराइड करने की आवश्यकता नहीं है, मैं अनुकूलित नहीं करूंगा।
java_mouse
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.