जावा कलेक्शन एपीआई में ग्राफ़ कार्यान्वयन क्यों नहीं है?

Question

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

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

मेरा पहला अनुमान यह है कि ग्राफ का प्रतिनिधित्व करने के लिए कोई सार्वभौमिक तरीका नहीं है, या उनके इंटरफेस उपयोगी होने के लिए एपीआई कार्यान्वयन के लिए सामान्य नहीं हो सकते हैं? लेकिन यदि आप अपने मूल घटकों (कोष्ठक और किनारों का एक सेट जो कुछ या सभी कोष्ठकों को जोड़ते हैं) पर एक ग्राफ को पट्टी करते हैं और उन तरीकों पर विचार करें जो ग्राफ सामान्य रूप से निर्मित होते हैं (addVertex (v) और insertEdge (v1, v2) जैसे तरीके) ऐसा लगता है कि एक सामान्य ग्राफ कार्यान्वयन संभव और उपयोगी होगा।

मुझे यह बेहतर समझने में मदद करने के लिए धन्यवाद।

Answer 1

ध्यान दें कि कुछ विशेष ग्राफ संग्रह फ्रेमवर्क में शामिल हैं, विशेष रूप से लिंक्ड सूचियों और पेड़।

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

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