java - जावा विधि से कई मान लौटें: क्यों एन-टुपल ऑब्जेक्ट्स नहीं?




methods return-type (4)

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

विशेष रूप से छोटी निजी विधियों के लिए सोचना जो दो ऑब्जेक्ट्स को एक साथ जोड़ सकते हैं (टंडेम में), और इस मामले में एक टाइप-ऑब्जेक्ट रिटर्न के रूप में ओवरकिल लगता है।


इसे पूरा करने के लिए बहुत सारे हैकिश तरीके हैं, एक तरीका Object[] वापस करना होगा, लेकिन फिर आपके पास चिंता करने के लिए सूचकांक हैं, और शून्य सूचक जांच, यह सिर्फ बुरा हो जाता है। एक और तरीका एक String वापस करना है, लेकिन फिर आपको इसे पार्स करना होगा, और यह बुरा हो जाता है।

मुझे लगता है कि असली सवाल क्यों है?

यहां रगड़ है - अगर मैं आपके साथ एक परियोजना पर काम कर रहा था, और मैंने इस तरह के व्यवहार को देखा, तो मैं इसे फिर से लिखूंगा ताकि आप देख सकें कि इसे कैसे संभाला जाना चाहिए। यदि आप कोड नमूना प्रदान करते हैं, तो मैं इसे चित्रित करने के लिए पुनः लिखूंगा।

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


चूंकि किसी विधि से एकाधिक मान लौटाते हुए एक अनुशंसित अभ्यास (जावा में) नहीं है।

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

अन्य भाषाओं में कई मान लौटाना (उदाहरण के लिए जाएं) उदाहरण के लिए एक एरर कोड लौटने के लिए उपयोग किया जाता है, लेकिन जावा को अपवादों का उपयोग करके अलग-अलग डिज़ाइन किया गया था।


पैटर्न की एक नई शैली उपलब्ध है, और "सभी असीमित" प्रकृति के साथ फिट बैठती है जिसे आप जावास्क्रिप्ट जैसी भाषाओं में देख सकते हैं।

मेरा बहुत सारे कोड आजकल ऐसा दिखता है :-)

public class Class1 {

    public interface Callback {
       void setData(String item1, String item2);
    }
    public void getThing(Callback callback) {
        callback.setData("a", "b");
    }
}

public class Class2 {

    public void doWithThing(Class1 o) {
        o.getThing(new Class1.Callback() {
            public void setData(String item1, String item2) {
                ... do something with item 1 and item 2 ...
            }
        });
    }

}

इंटरफ़ेस के बाद से कई अतिरिक्त कक्षाएं बनाने के लिए कोई नई वस्तुएं नहीं हैं और ऑब्जेक्ट का आंतरिक वर्ग नहीं है।

यह स्विफ्ट को इतना भयानक बनाता है। कोड इस तरह दिख सकता है:

o.getThing({ item1, item2 -> Void in
    ... do something with item 1 and item 2 ...
});

और चूंकि एकमात्र तर्क ब्लॉक है, यहां तक ​​कि यह भी:

o.getThing { item1, item2 -> Void in
    ... do something with item 1 and item 2 ...
};

जावा को कॉलबैक लडेन कोड को पढ़ने के लिए बहुत आसान बनाने के लिए काम की ज़रूरत है।


मुझे लगता है कि ओपी का मतलब है "जावा एन-ट्यूपल ऑब्जेक्ट्स का समर्थन क्यों नहीं करता?"। पाइथन, हास्केल, लिस्प, एमएल आदि में विषम एन-ट्यूपल क्षमताएं हैं। अक्सर एक भाषा में कई वस्तुओं को स्पष्ट रूप से वापस करने की क्षमता सिंटैक्टिकल चीनी (यानी पाइथन रिटर्न 'ए', 'बी') में होती है।

पाठ्यक्रम का कारण भाषा डिजाइन और स्थिरता है। जावा बहुत स्पष्ट होना पसंद करता है और अनाम डेटा संरचनाओं को पसंद नहीं करता है (हालांकि मेरी इच्छा है कि हमारे पास अनाम बंद हो)।

उदाहरण के लिए जावा में कहने का कोई तरीका नहीं है कि मुझे कॉलबैक चाहिए जो इन प्रकार के पैरामीटर लेता है और इसे वापस करता है। कुछ लोग इस तरह की एक बड़ी कमजोरी महसूस करते हैं जैसे कि स्थिरता और स्पष्टीकरण।

आईएमएचओ हालांकि इसके कष्टप्रद मैं अक्सर स्थिर इनलाइन कक्षाओं बनाकर इस मुद्दे का मुकाबला करता हूं:

private static class Combo {
   String name;
   int weight;
}

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

मुझे ध्यान रखना चाहिए कि 2-टुपल्स के लिए कुछ लोग java.util.Map.Entry उपयोग करते हैं क्योंकि java.util.AbstractMap.SimpleEntry में एक java.util.AbstractMap.SimpleEntry है 6. इसके अलावा कुछ लोग अब कॉमन्स लैंग 3 के जोड़े समर्थन (2-टुपल) का उपयोग करते हैं )

स्कैला के पास धोखाधड़ी के प्रकार एन-टुपल समर्थन है और 2-16 ट्यूपल इंटरफेस का पूरा समूह है जो भाषा में मानक है और प्रोग्रामर से वाक्य रचनात्मक रूप से छिपा हुआ है।

पूरी तरह से शैक्षिक कारणों से आप देखना चाहते हैं कि अन्य भाषाएं इसे कैसे पूरा करती हैं

अद्यतन: जावा 8 के लिए

जावा 8 होगा / हो सकता है (तो मेरा नंबर है ... मुझे कॉल करें) एक इंटरफ़ेस का समर्थन करें जिसे java.lang.BiValue नामक एक ठोस कार्यान्वयन के साथ प्रयोग किया जाता है जिसे आप java.lang.BiVal कहते java.lang.BiVal । ये कक्षाएं नई लैम्ब्डा कार्यक्षमता का समर्थन करने में मदद करने के लिए हैं। लेकिन ध्यान दें कि यह केवल 2-टुपल्स के लिए है।

अद्यतन: 2015 के लिए

जावा 8 को टुपल्स के लिए समर्थन नहीं मिला।

अद्यतन: लेखक 2015 से

यदि आप अभी भी ट्यूपल समर्थन चाहते हैं तो तीन पुस्तकालय हैं जो टुपल्स को अच्छी तरह से समर्थन देते हैं:

  • javatuples - javatuples 5 और ऊपर का समर्थन करता है। 10-टुपल तक।
  • JOOλ - JOOλ के लेखक से लेकिन जेडीके 8 की आवश्यकता है।
  • कॉमन्स लैंग 3 - अब एक ट्रिपल (3-ट्यूपल) का समर्थन करता है और जेडीके 6 और उससे ऊपर का समर्थन करता है।




return-type