मुझे लगता है कि कुछ मजबूत कारण होना चाहिए कि उन्होंने इसे संग्रह API में शामिल न करने का निर्णय क्यों लिया।
मुझे लगता है कि कारण यह है कि कोई भी दोनों
- सामान्य प्रयोजन के लिए पर्याप्त का उपयोग-मामले एक विस्तृत श्रृंखला को कवर करने के लिए है कि पेड़ के लिए एक अच्छा एपीआई के साथ आ गया है, और
- उपयोगी सामान्य होने के प्रदर्शन ओवरहेड्स की भरपाई करने के लिए पर्याप्त है।
(और तुम कहाँ रोक सकता हूं? ट्री? द्विआधारी पेड़? एन-ary पेड़? DAG? ग्राफ़?)
यह है कि न तो अपाचे कॉमन्स संग्रह या गूगल संग्रह (उर्फ अमरूद) एक है ध्यान देने योग्य है पेड़ एपीआई। हालांकि, इस विषय पर एक सक्रिय अमरूद मुद्दा है - http://code.google.com/p/guava-libraries/issues/detail?id=174 - स्पष्ट रूप से कम से कम कुछ लोग आपके दृष्टिकोण से सहमत हैं।
अद्यतन
संस्करण 15.0 के रूप में, अमरूद अब TreeTraverser
और BinaryTreeTraverser
वर्गों के रूप में पेड़ समर्थन हासिल है। लेकिन यह वही नहीं हो सकता है जो आप उम्मीद करते हैं। सच में, ये वर्ग वास्तव में पेड़ डेटा संरचना को लागू नहीं करते हैं। इसके बजाय, आपको इसे सामान्य प्रकार पैरामीटर में करना होगा। इसके अलावा, Traverser
कक्षाएं नोड प्रकार के एपीआई के बारे में धारणाएं करने से बचती हैं। वे अमूर्त कक्षाओं के द्वारा ऐसा करते हैं, और पेड़ से पूछताछ करने वाले संचालन को लागू करने के लिए कंक्रीट ट्रैवर्सर उप प्रकार की आवश्यकता होती है; जैसे नोड के बच्चे प्राप्त करने के लिए।
Fwiw, TreeMap
और TreeSet
"पेड़ एपीआई" नहीं हैं। वे पेड़-आधारित कार्यान्वयन Map
और Set
एपीआई हैं। पेड़-नस्ल पूरी तरह से सार्वजनिक एपीआई द्वारा छुपाया जाता है, जिससे इन दो वर्गों को सामान्य प्रयोजन के पेड़ों के रूप में उपयोग के लिए पूरी तरह से अनुपयुक्त बना दिया जाता है।
स्रोत
2011-12-27 07:25:10
yup, वास्तव में दिलचस्प – Eugene
ट्रीसेट और ट्रीमैप दो संग्रह हैं जो बाइनरी पेड़ द्वारा समर्थित हैं। –
मैं केवल बाइनरी पेड़ की बात नहीं कर रहा हूं, हमारे पास एक सामान्यीकृत पेड़ कार्यान्वयन क्यों नहीं है, एक वृक्ष इंटीफेस? –