2011-12-27 14 views
15

जिज्ञासा से बाहर, मुझे हाल ही में अपने कार्यक्रमों में से एक के लिए एक पेड़ का उपयोग करना पड़ा, मुझे खुद को एक बाइनरी पेड़ बनाना पड़ा, लेकिन कलेक्शन एपीआई में डिफ़ॉल्ट क्यों नहीं है पेड़ के कार्यान्वयन (या यहां तक ​​कि एक बाइनरी पेड़)?क्यों जावा कलेक्शन एपीआई में वृक्ष कार्यान्वयन नहीं है

मुझे लगता है कि कुछ मजबूत कारण होना चाहिए कि उन्होंने इसे संग्रह API में शामिल न करने का निर्णय क्यों लिया।

+0

yup, वास्तव में दिलचस्प – Eugene

+4

ट्रीसेट और ट्रीमैप दो संग्रह हैं जो बाइनरी पेड़ द्वारा समर्थित हैं। –

+0

मैं केवल बाइनरी पेड़ की बात नहीं कर रहा हूं, हमारे पास एक सामान्यीकृत पेड़ कार्यान्वयन क्यों नहीं है, एक वृक्ष इंटीफेस? –

उत्तर

0

java.util.TreeMap लाल और काले पेड़ का कार्यान्वयन है।

+0

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

+0

मैं आर्टिम झ के जवाब से सहमत हूं। वृक्ष संस्थाओं का "संग्रह" रखने के लिए डेटा संरचना का एक विशिष्ट रूप है। – Scorpion

10

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

बीटीडब्ल्यू, जावा में कक्षाओं ("रेड-ब्लैक ट्री आधारित नेविगैबल मैप कार्यान्वयन") और ट्रीसेट ("ट्रीमैप पर आधारित एक नेविगेटसेट कार्यान्वयन") कक्षाएं हैं।

+0

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

+1

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

15

मुझे लगता है कि कुछ मजबूत कारण होना चाहिए कि उन्होंने इसे संग्रह API में शामिल न करने का निर्णय क्यों लिया।

मुझे लगता है कि कारण यह है कि कोई भी दोनों

  • सामान्य प्रयोजन के लिए पर्याप्त का उपयोग-मामले एक विस्तृत श्रृंखला को कवर करने के लिए है कि पेड़ के लिए एक अच्छा एपीआई के साथ आ गया है, और
  • उपयोगी सामान्य होने के प्रदर्शन ओवरहेड्स की भरपाई करने के लिए पर्याप्त है।

(और तुम कहाँ रोक सकता हूं? ट्री? द्विआधारी पेड़? एन-ary पेड़? DAG? ग्राफ़?)

यह है कि न तो अपाचे कॉमन्स संग्रह या गूगल संग्रह (उर्फ अमरूद) एक है ध्यान देने योग्य है पेड़ एपीआई। हालांकि, इस विषय पर एक सक्रिय अमरूद मुद्दा है - http://code.google.com/p/guava-libraries/issues/detail?id=174 - स्पष्ट रूप से कम से कम कुछ लोग आपके दृष्टिकोण से सहमत हैं।

अद्यतन

संस्करण 15.0 के रूप में, अमरूद अब TreeTraverser और BinaryTreeTraverser वर्गों के रूप में पेड़ समर्थन हासिल है। लेकिन यह वही नहीं हो सकता है जो आप उम्मीद करते हैं। सच में, ये वर्ग वास्तव में पेड़ डेटा संरचना को लागू नहीं करते हैं। इसके बजाय, आपको इसे सामान्य प्रकार पैरामीटर में करना होगा। इसके अलावा, Traverser कक्षाएं नोड प्रकार के एपीआई के बारे में धारणाएं करने से बचती हैं। वे अमूर्त कक्षाओं के द्वारा ऐसा करते हैं, और पेड़ से पूछताछ करने वाले संचालन को लागू करने के लिए कंक्रीट ट्रैवर्सर उप प्रकार की आवश्यकता होती है; जैसे नोड के बच्चे प्राप्त करने के लिए।


Fwiw, TreeMap और TreeSet "पेड़ एपीआई" नहीं हैं। वे पेड़-आधारित कार्यान्वयन Map और Set एपीआई हैं। पेड़-नस्ल पूरी तरह से सार्वजनिक एपीआई द्वारा छुपाया जाता है, जिससे इन दो वर्गों को सामान्य प्रयोजन के पेड़ों के रूप में उपयोग के लिए पूरी तरह से अनुपयुक्त बना दिया जाता है।

संबंधित मुद्दे