जावा में C ++ जोड़ी <L, R> के बराबर क्या है?


670

क्या Pair<L,R>जावा में कोई कारण नहीं है एक अच्छा कारण है ? इस C ++ कंस्ट्रक्शन के बराबर क्या होगा? मैं अपने स्वयं के पुन: कार्यान्वयन से बचना चाहूंगा।

ऐसा लगता है कि 1.6 कुछ समान प्रदान कर रहा है ( AbstractMap.SimpleEntry<K,V>), लेकिन यह काफी जटिल है।


7
क्यों AbstractMap.SimpleEntryसजाया जाता है?
कर्टनडॉग

27
नामीग की वजह से, एक कुंजी और एक मूल्य का नामकरण मनमाना।
Enerccio

2
यह भी देखें stackoverflow.com/questions/6271731/…
Raedwald

2
@sffc JavaFX JDK7 में किसी भी डिफ़ॉल्ट क्लासपैथ पर नहीं है, इसका उपयोग करने के लिए JFX रनटाइम लाइब्रेरीज़ को मैन्युअल रूप से जोड़ना होगा।
कॉर्ड रेहान

3
@Enerccio: तो, आप वास्तव में बताते हैं कि "प्रथम" और "दूसरा" मनमाना नहीं है, जबकि "कुंजी" और "मूल्य" - है? तब एसडीके में इस तरह की क्लास नहीं होने का यह एक अच्छा कारण है। "उचित" नामकरण के बारे में सार्वकालिक विवाद होगा।
fdreger 19

जवाबों:


400

में पर एक धागाcomp.lang.java.help , हंटर Gratzner एक की उपस्थिति के खिलाफ कुछ तर्क देता है Pairजावा में निर्माण। मुख्य तर्क यह है कि एक वर्ग Pairकिसी भी शब्दार्थ को दो मूल्यों के बीच संबंध के बारे में नहीं बताता है (आप कैसे जानते हैं कि "पहले" और "दूसरे" का क्या मतलब है?)।

एक बेहतर अभ्यास एक बहुत ही सरल वर्ग लिखना है, जैसे कि आपके द्वारा बनाए गए प्रत्येक एप्लिकेशन के लिए एक माइक प्रस्तावित है PairMap.Entryएक जोड़ी का एक उदाहरण है जो इसके अर्थ को अपने नाम पर ले जाता है।

योग करने के लिए, मेरी राय में एक सामान्य के बजाय एक वर्ग Position(x,y), एक वर्ग Range(begin,end)और एक वर्ग होना बेहतर है जो मुझे कुछ भी नहीं बताता है कि यह क्या करना चाहिए।Entry(key,value)Pair(first,second)


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

25
इयान से सहमत हूं। जावा आपको int लौटने देता है; यह आपको हर बार जब आप एक का उपयोग करने के लिए एक उपनाम बनाने के लिए मजबूर नहीं करता है। जोड़े बहुत अलग नहीं हैं।
क्लेमेंट

5
अगर हम एक जोड़ी को सीधे आपके स्थानीय चर में अनपैक कर सकते हैं, या इसे एक विधि के लिए आगे बढ़ा सकते हैं जो दो तर्क देता है, तो पेयर एक उपयोगी वर्ग होगा। चूंकि हम इसे इस तरह से अनपैक नहीं कर सकते हैं, एक सार्थक वर्ग का निर्माण और मूल्यों को एक साथ रखना बहुत बुरा नहीं लगता है। और, यदि आप वास्तव में सीमाओं के बावजूद एक जोड़ी चाहते हैं, तो हमेशा ऑब्जेक्ट [2] + कास्ट्स :-)
marcus

बात यह है कि यदि आप Gratzner से असहमत हैं, तो कई स्थानों पर Pair कार्यान्वयन है। Apache Commons और Guava दोनों में यह IIRC है। उन का उपयोग करें। लेकिन मुख्य जावा पुस्तकालयों में कुछ डालने का मतलब है कि यह एक बड़ा और स्वीकृत तरीका है जो चीजों को (पूंजीकरण के साथ) कर रहा है और चूंकि लोग इस पर सहमत नहीं हैं, इसलिए हमें इसे वहां नहीं रखना चाहिए। पुराने कामों में पर्याप्त रूप से कमी है, चलो वहाँ ज्यादा नहीं डाला।
हाकोन लोविटविट

1
@Dragas जब मुझे मूल्यों की एक जोड़ी की आवश्यकता होती है, तो वह जावा नहीं ... गंभीरता से?
आईडीक्लेव ४६३०३५18१

156

यह जावा है। आपको वर्णनात्मक वर्ग और क्षेत्र के नामों के साथ अपना खुद का सिलवाया हुआ पेयर क्लास बनाना होगा, न कि यह ध्यान में रखते हुए कि आप हैशकोड () / बराबर () लिखकर या बार-बार तुलनात्मक रूप से लागू करके पहिए को फिर से मजबूत करेंगे।


61
इस सवाल का जवाब "क्यों" नहीं है। (जब तक आप 'यह एक जावा है' एक उत्तर पर विचार करें)
निकिता रायबाक

127
जावा की वाचालता का मजाक उड़ाने के लिए +1। -1 वास्तव में सवाल का जवाब नहीं देने के लिए।
बेनेट मैकलेवे

19
यदि आपने अपाचे कमांडॉन्ग लैंग की ओर इशारा किया होता तो जावा-मॉकरी ठीक होती, जिसमें एक पेयर क्लास होती है।
9

6
या आप बस इस्तेमाल कर सकते हैंSimpleImmutableEntry
कर्टनडॉग

33
पहला वाक्य प्रश्न "क्यों?" का उत्तर देता है। यह जावा है, और यही है।
मास्टरज़िव

103

HashMap संगत जोड़ी वर्ग:

public class Pair<A, B> {
    private A first;
    private B second;

    public Pair(A first, B second) {
        super();
        this.first = first;
        this.second = second;
    }

    public int hashCode() {
        int hashFirst = first != null ? first.hashCode() : 0;
        int hashSecond = second != null ? second.hashCode() : 0;

        return (hashFirst + hashSecond) * hashSecond + hashFirst;
    }

    public boolean equals(Object other) {
        if (other instanceof Pair) {
            Pair otherPair = (Pair) other;
            return 
            ((  this.first == otherPair.first ||
                ( this.first != null && otherPair.first != null &&
                  this.first.equals(otherPair.first))) &&
             (  this.second == otherPair.second ||
                ( this.second != null && otherPair.second != null &&
                  this.second.equals(otherPair.second))) );
        }

        return false;
    }

    public String toString()
    { 
           return "(" + first + ", " + second + ")"; 
    }

    public A getFirst() {
        return first;
    }

    public void setFirst(A first) {
        this.first = first;
    }

    public B getSecond() {
        return second;
    }

    public void setSecond(B second) {
        this.second = second;
    }
}

136
आप शायद बसने वालों को हटाना चाहते हैं, और पहले और दूसरे फाइनल में पहुँचते हैं, इस प्रकार यह जोड़ी को अपरिवर्तनीय बनाता है। (यदि किसी ने हैश कुंजी के रूप में उपयोग करने के बाद घटकों को बदल दिया, तो अजीब चीजें होंगी)।
थिलो

21
वापसी "(" + first.toString () + "," + second.toString () + ")" toString () विधि NullPointerException फेंक सकते हैं। यह बेहतर है: वापसी "(" + प्रथम + "," + दूसरा + ")";
जूहा सिरजला

6
इसके अलावा, या तो जोड़ी को "अंतिम" के रूप में चिह्नित करें या बराबर की पहली पंक्ति को 'अगर (अन्य! = Null && this.getClass () == other.getClass ())'
sargas

8
बेतरतीब नोबी प्रश्न के लिए क्षमा करें, लेकिन आपके पास कंस्ट्रक्टर में सुपर () के लिए कॉल क्यों है?
इब्राहिम

6
@ इब्राहिम: इस मामले में, यह शानदार है --- व्यवहार बिल्कुल वैसा ही है जैसे आपने super()बाहर निकाल लिया । आम तौर पर मैं इसे बंद कर देता हूँ अगर यह वैकल्पिक है, जैसे कि यह यहाँ है।
क्रिस जस्टर-यंग

53

लोम्बोक का उपयोग करते हुए, मैं सबसे छोटी जोड़ी बन सकती हूं :

@Data
@AllArgsConstructor(staticName = "of")
public class Pair<F, S> {
    private F first;
    private S second;
}

यह के सभी लाभ है @arturh से जवाब (तुलनीयता को छोड़कर) यह है, hashCode, equals, toStringऔर एक स्थिर "निर्माता"।


निफ्टी! अच्छा लगा!
अहमत इपकीन


31

के साथ जोड़ी को लागू करने का एक और तरीका है।

  • सार्वजनिक अपरिवर्तनीय क्षेत्र, अर्थात सरल डेटा संरचना।
  • तुलनीय।
  • सरल हैश और बराबर है।
  • सरल कारखाने इसलिए आपको प्रकार प्रदान करने की आवश्यकता नहीं है। उदाहरण Pair.of ("हैलो", 1);

    public class Pair<FIRST, SECOND> implements Comparable<Pair<FIRST, SECOND>> {
    
        public final FIRST first;
        public final SECOND second;
    
        private Pair(FIRST first, SECOND second) {
            this.first = first;
            this.second = second;
        }
    
        public static <FIRST, SECOND> Pair<FIRST, SECOND> of(FIRST first,
                SECOND second) {
            return new Pair<FIRST, SECOND>(first, second);
        }
    
        @Override
        public int compareTo(Pair<FIRST, SECOND> o) {
            int cmp = compare(first, o.first);
            return cmp == 0 ? compare(second, o.second) : cmp;
        }
    
        // todo move this to a helper class.
        private static int compare(Object o1, Object o2) {
            return o1 == null ? o2 == null ? 0 : -1 : o2 == null ? +1
                    : ((Comparable) o1).compareTo(o2);
        }
    
        @Override
        public int hashCode() {
            return 31 * hashcode(first) + hashcode(second);
        }
    
        // todo move this to a helper class.
        private static int hashcode(Object o) {
            return o == null ? 0 : o.hashCode();
        }
    
        @Override
        public boolean equals(Object obj) {
            if (!(obj instanceof Pair))
                return false;
            if (this == obj)
                return true;
            return equal(first, ((Pair) obj).first)
                    && equal(second, ((Pair) obj).second);
        }
    
        // todo move this to a helper class.
        private boolean equal(Object o1, Object o2) {
            return o1 == null ? o2 == null : (o1 == o2 || o1.equals(o2));
        }
    
        @Override
        public String toString() {
            return "(" + first + ", " + second + ')';
        }
    }

10
मुझे स्टैटिक फैक्ट्री विधि पसंद है of। यह Google अमरूद के संग्रहणीय संग्रह की याद दिलाता है ।
जारेक प्रोजगोडकी

7
आप कुछ बिंदुओं पर कास्टिंग o1कर रहे हैं Comparable, भले ही यह इंगित नहीं करता है कि यह वास्तव में उस इंटरफ़ेस को लागू करेगा। यदि वह आवश्यकता है, तो FIRSTटाइप पैरामीटर होना चाहिए FIRST extends Comparable<?>
G_H

मैं एक जावा आदमी नहीं हूं, इसलिए कृपया मुझे मेरी अज्ञानता के लिए क्षमा करें, लेकिन TODO टिप्पणियों में आप किस प्रकार के सहायक वर्ग के बारे में सोच रहे थे?

3
31 हैशकोड के लिए एक बुरा स्थिरांक है। उदाहरण के लिए, यदि आप 2 डी मानचित्र के लिए पेयर <Integer, Integer> के द्वारा HashMap कुंजी का उपयोग करते हैं, तो आपको कई टकराव मिलेंगे। उदाहरण के लिए (* * 65497) ^ b बेहतर अनुकूल होगा।
18:30 पर मिशाल ज़िलिस्की

1
@MarioCarneiro ^ xor है, शक्ति नहीं है
Michał

27

कैसे के बारे में http://www.javatuples.org/index.html मैंने इसे बहुत उपयोगी पाया है।

Javatuples आपको एक से दस तत्वों तक की तुच्छ कक्षाएं प्रदान करता है:

Unit<A> (1 element)
Pair<A,B> (2 elements)
Triplet<A,B,C> (3 elements)
Quartet<A,B,C,D> (4 elements)
Quintet<A,B,C,D,E> (5 elements)
Sextet<A,B,C,D,E,F> (6 elements)
Septet<A,B,C,D,E,F,G> (7 elements)
Octet<A,B,C,D,E,F,G,H> (8 elements)
Ennead<A,B,C,D,E,F,G,H,I> (9 elements)
Decade<A,B,C,D,E,F,G,H,I,J> (10 elements)

6
मजेदार है, लेकिन कम से कम 5 और कक्षाएं हैं जो मैं कभी भी उपयोग करने की कल्पना कर सकता हूं।
मआर्टिनस

3
@maaartinus मेरे द्वारा उपयोग किए जाने से कम से कम 10 अधिक।
बोएन

7
@ बोआन: ठीक है, मैं सही रहूँ। मैं उपयोग करता था Pairऔर Tripletहर 50 साल में एक बार उपयोग करने की कल्पना कर सकता था। अब मैं लोम्बोक का उपयोग करता हूं और हर बार मुझे एक जोड़ी की आवश्यकता के लिए एक 4-लाइन क्लास बनाता हूं। तो "10 बहुत अधिक" सटीक है।
Maaartinus

5
क्या हमें एक Bottom (0 element)वर्ग की आवश्यकता है ? :)
पृथ्वी इंजन

2
वाह यह बदसूरत है। मुझे पता है कि वे इसे स्पष्ट करने की कोशिश कर रहे हैं, लेकिन T # जैसे अतिभारित परम्परों के साथ एक टपल अच्छा होगा।
अरविमान

12

यह इस बात पर निर्भर करता है कि आप इसका क्या उपयोग करना चाहते हैं। ऐसा करने का विशिष्ट कारण नक्शों पर चलना है, जिसके लिए आप बस ऐसा करते हैं (जावा 5+):

Map<String, Object> map = ... ; // just an example
for (Map.Entry<String, Object> entry : map.entrySet()) {
  System.out.printf("%s -> %s\n", entry.getKey(), entry.getValue());
}

1
मुझे यकीन नहीं है कि एक कस्टम वर्ग इस मामले में मदद करेगा :)
निकिता रायबाक

31
"ऐसा करने का विशिष्ट कारण नक्शों पर चलना है"। वास्तव में?
बेनेट मैकलेवे

12

एंड्रॉइड Pairकक्षा प्रदान करता है ( http://developer.android.com/reference/android/util/Pair.html ), यहां कार्यान्वयन:

public class Pair<F, S> {
    public final F first;
    public final S second;

    public Pair(F first, S second) {
        this.first = first;
        this.second = second;
    }

    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Pair)) {
            return false;
        }
        Pair<?, ?> p = (Pair<?, ?>) o;
        return Objects.equal(p.first, first) && Objects.equal(p.second, second);
    }

    @Override
    public int hashCode() {
        return (first == null ? 0 : first.hashCode()) ^ (second == null ? 0 : second.hashCode());
    }

    public static <A, B> Pair <A, B> create(A a, B b) {
        return new Pair<A, B>(a, b);
    }
}

1
Objects.equal(..)अमरूद पुस्तकालय की आवश्यकता है।
मार्कस एल

3
इसे बदलें Objects.equals(...)जो 2011 (1.7) से जावा में रहा है।
एंड्रयूएफ

9

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

वैसे भी, @ पीटरलेव्रे के जवाब से जेनेरिक चेतावनियों को साफ़ करना (java 1.7):

public class Pair<A extends Comparable<? super A>,
                    B extends Comparable<? super B>>
        implements Comparable<Pair<A, B>> {

    public final A first;
    public final B second;

    private Pair(A first, B second) {
        this.first = first;
        this.second = second;
    }

    public static <A extends Comparable<? super A>,
                    B extends Comparable<? super B>>
            Pair<A, B> of(A first, B second) {
        return new Pair<A, B>(first, second);
    }

    @Override
    public int compareTo(Pair<A, B> o) {
        int cmp = o == null ? 1 : (this.first).compareTo(o.first);
        return cmp == 0 ? (this.second).compareTo(o.second) : cmp;
    }

    @Override
    public int hashCode() {
        return 31 * hashcode(first) + hashcode(second);
    }

    // TODO : move this to a helper class.
    private static int hashcode(Object o) {
        return o == null ? 0 : o.hashCode();
    }

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Pair))
            return false;
        if (this == obj)
            return true;
        return equal(first, ((Pair<?, ?>) obj).first)
                && equal(second, ((Pair<?, ?>) obj).second);
    }

    // TODO : move this to a helper class.
    private boolean equal(Object o1, Object o2) {
        return o1 == o2 || (o1 != null && o1.equals(o2));
    }

    @Override
    public String toString() {
        return "(" + first + ", " + second + ')';
    }
}

परिवर्धन / सुधार बहुत स्वागत करते हैं :) विशेष रूप से मैं अपने उपयोग के बारे में निश्चित नहीं हूं Pair<?, ?>

इस सिंटैक्स के बारे में अधिक जानकारी के लिए यह सुनिश्चित करें कि ऑब्जेक्ट तुलनात्मक और एक विस्तृत विवरण के लिए लागू होते हैं max(Comparable a, Comparable b)जावा में एक सामान्य फ़ंक्शन को कैसे लागू किया जाए ?


जैसा कि Java Integers 32 बिट हैं, पहले हैशकोड को 31 से गुणा नहीं करेंगे, इसका मतलब यह है कि यह ओवरफ्लो होता है? क्या एक विशेष OR प्रदर्शन करना बेहतर नहीं होगा?
डैन

@ मुझे लगता है कि मैं जावा से दूर स्थानांतरित करने के लिए स्वतंत्र महसूस कर रहा हूँ :)
Mr_and_Mrs_D

5

मेरी राय में, जावा में कोई जोड़ी नहीं है क्योंकि, यदि आप सीधे जोड़ी पर अतिरिक्त कार्यक्षमता जोड़ना चाहते हैं (जैसे तुलनीय), तो आपको प्रकारों को बाध्य करना होगा। C ++ में, हम सिर्फ परवाह नहीं करते हैं, और यदि एक जोड़ी की रचना के प्रकार नहीं हैं operator <, तो pair::operator <संकलन भी नहीं होगा।

कोई सीमा नहीं के साथ तुलना का एक उदाहरण:

public class Pair<F, S> implements Comparable<Pair<? extends F, ? extends S>> {
    public final F first;
    public final S second;
    /* ... */
    public int compareTo(Pair<? extends F, ? extends S> that) {
        int cf = compare(first, that.first);
        return cf == 0 ? compare(second, that.second) : cf;
    }
    //Why null is decided to be less than everything?
    private static int compare(Object l, Object r) {
        if (l == null) {
            return r == null ? 0 : -1;
        } else {
            return r == null ? 1 : ((Comparable) (l)).compareTo(r);
        }
    }
}

/* ... */

Pair<Thread, HashMap<String, Integer>> a = /* ... */;
Pair<Thread, HashMap<String, Integer>> b = /* ... */;
//Runtime error here instead of compile error!
System.out.println(a.compareTo(b));

इस प्रकार के तर्कों की तुलना के लिए संकलन-समय की जाँच के साथ तुलना का एक उदाहरण:

public class Pair<
        F extends Comparable<? super F>, 
        S extends Comparable<? super S>
> implements Comparable<Pair<? extends F, ? extends S>> {
    public final F first;
    public final S second;
    /* ... */
    public int compareTo(Pair<? extends F, ? extends S> that) {
        int cf = compare(first, that.first);
        return cf == 0 ? compare(second, that.second) : cf;
    }
    //Why null is decided to be less than everything?
    private static <
            T extends Comparable<? super T>
    > int compare(T l, T r) {
        if (l == null) {
            return r == null ? 0 : -1;
        } else {
            return r == null ? 1 : l.compareTo(r);
        }
    }
}

/* ... */

//Will not compile because Thread is not Comparable<? super Thread>
Pair<Thread, HashMap<String, Integer>> a = /* ... */;
Pair<Thread, HashMap<String, Integer>> b = /* ... */;
System.out.println(a.compareTo(b));

यह अच्छा है, लेकिन इस बार आप जोड़ी में तर्क के रूप में गैर-तुलनीय प्रकार का उपयोग नहीं कर सकते हैं। कुछ उपयोगिता वर्ग में जोड़ी के लिए बहुत सारे कम्पेसाटर का उपयोग कर सकते हैं, लेकिन C ++ लोग इसे प्राप्त नहीं कर सकते हैं। एक और तरीका यह है कि टाइप आर्ग्युमेंट पर अलग-अलग सीमा के साथ एक प्रकार की पदानुक्रम में बहुत सारी कक्षाएं लिखी जाएं, लेकिन बहुत सारे संभावित सीमाएं और उनके संयोजन हैं ...


5

जावाएफ़एक्स (जो जावा 8 के साथ बंडल में आता है) में पेयर <ए, बी> क्लास है


1
Javafx.util.Pair में hashCode के कार्यान्वयन तुच्छ मामलों पर टकराव हो सकता है। हैशपॉप / हैशटेबल में इसका उपयोग करना तब भी काम करेगा क्योंकि हैश कोड के अलावा मूल्यों की समानता के लिए जावा जांच करता है, लेकिन इसके बारे में पता होना चाहिए।
sffc

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

5

जैसा कि कई अन्य पहले ही बता चुके हैं, यह वास्तव में उपयोग के मामले पर निर्भर करता है कि क्या एक जोड़ी वर्ग उपयोगी है या नहीं।

मुझे लगता है कि एक निजी सहायक फ़ंक्शन के लिए यह पूरी तरह से एक वैध वर्ग का उपयोग करने के लिए वैध है यदि यह आपके कोड को अधिक पठनीय बनाता है और अपने सभी बॉयलर प्लेट कोड के साथ एक और मूल्य वर्ग बनाने के प्रयास के लायक नहीं है।

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

हमेशा की तरह, इसे कुशल निर्णय की आवश्यकता है।

आपके दूसरे प्रश्न के लिए मैं अपाचे कॉमन्स पुस्तकालयों से पेयर वर्ग की सिफारिश करता हूं। उन्हें जावा के लिए विस्तारित मानक पुस्तकालयों के रूप में माना जा सकता है:

https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/Pair.html

आप Apache Commons के EqualsBuilder , HashCodeBuilder और ToStringBuilder पर भी एक नज़र रखना चाहते हैं , जो आपके व्यवसाय की वस्तुओं के लिए लेखन मूल्य वर्गों को सरल बनाती है।


अपडेट किया गया URL commons.apache.org/lang/api-release/index.html?org/apache/… है क्योंकि कॉमन्स- lang3 बीटा से बाहर है। यह मेरे अपने
लोम्बोक


5

अच्छी खबर JavaFXका एक महत्वपूर्ण मूल्य है जोड़ी।

बस एक निर्भरता और आयात के रूप में javafx जोड़ें javafx.util.Pair;

और के रूप में बस का उपयोग c++

Pair <Key, Value> 

जैसे

Pair <Integer, Integer> pr = new Pair<Integer, Integer>()

pr.get(key);// will return corresponding value

बुरी खबर यह है कि हर कोई JavaFX का उपयोग नहीं करता है
Michał Dobi Dobrza Mayski

4

Map.Entry इंटरफ़ेस c ++ जोड़ी के बहुत करीब आता है। ठोस कार्यान्वयन को देखें, जैसे AbstractMap.SimpleEntry और AbstractMap.SimpleImmutableEntry पहला आइटम getKey () है और दूसरा getValue () है।


1
ओपी को पहले से ही इस विकल्प के बारे में पता है, और इस पर चर्चा की गई।
कीगन


3

जावा भाषा की प्रकृति के अनुसार, मुझे लगता है कि लोगों को वास्तव में एक की आवश्यकता नहीं है Pair, एक इंटरफ़ेस आमतौर पर वह होता है जिसकी उन्हें आवश्यकता होती है। यहाँ एक उदाहरण है:

interface Pair<L, R> {
    public L getL();
    public R getR();
}

इसलिए, जब लोग दो मूल्यों को वापस करना चाहते हैं तो वे निम्नलिखित कार्य कर सकते हैं:

... //Calcuate the return value
final Integer v1 = result1;
final String v2 = result2;
return new Pair<Integer, String>(){
    Integer getL(){ return v1; }
    String getR(){ return v2; }
}

यह एक बहुत ही हल्का समाधान है, और यह प्रश्न का उत्तर देता है "एक का अर्थ क्या है Pair<L,R>?"। जवाब है, यह दो (अलग हो सकता है) प्रकार के साथ एक इंटरफ़ेस बिल्ड है, और इसमें उनमें से प्रत्येक को वापस करने के तरीके हैं। यह आप पर निर्भर है कि आप इसमें और शब्दार्थ जोड़ सकते हैं। उदाहरण के लिए, यदि आप स्थिति का उपयोग कर रहे हैं और वास्तव में आप इसे कोड में इंगित करना चाहते हैं, तो आप परिभाषित कर सकते हैं PositionXऔर PositionYइसमें शामिल हैं Integer, एक बनाने के लिए Pair<PositionX,PositionY>। यदि JSR 308 उपलब्ध है, तो आप इसे Pair<@PositionX Integer, @PositionY Ingeger>सरल बनाने के लिए भी उपयोग कर सकते हैं ।

संपादित करें: एक बात जो मुझे यहाँ इंगित करनी चाहिए वह यह है कि उपरोक्त परिभाषा स्पष्ट रूप से टाइप पैरामीटर नाम और विधि नाम से संबंधित है। यह उन लोगों के लिए एक तर्क है कि एक Pairअर्थ संबंधी जानकारी का अभाव है। दरअसल, विधि का getLअर्थ है "मुझे वह तत्व दें जो टाइप पैरामीटर एल के प्रकार के अनुरूप है", जिसका अर्थ कुछ है।

संपादित करें: यहाँ एक सरल उपयोगिता वर्ग है जो जीवन को आसान बना सकता है:

class Pairs {
    static <L,R> Pair<L,R> makePair(final L l, final R r){
        return new Pair<L,R>(){
            public L getL() { return l; }
            public R getR() { return r; }   
        };
    }
}

उपयोग:

return Pairs.makePair(new Integer(100), "123");

किस बारे में equals, hashCodeऔर toString?
sdgfsdh

ठीक है, यह सिर्फ एक न्यूनतम कार्यान्वयन है। यदि आपको इससे अधिक की आवश्यकता है, तो आप इसे आसान बनाने के लिए कुछ सहायक कार्य लिख सकते हैं, लेकिन फिर भी आपको कोड लिखना होगा।
पृथ्वी इंजन

लागू करने के लिए toStringआपको दो क्षेत्रों के बीच संबंध के बारे में अधिक जानकारी की आवश्यकता है।
पृथ्वी इंजन

मेरा कहना है कि यह classसिर्फ interfaceइसलिए बेहतर हो सकता है क्योंकि यह इन चीजों को लागू कर सकता है।
sdgfsdh

3

वाक्यात्मक रूप से समान होने के बावजूद, जावा और सी ++ में बहुत अलग प्रतिमान हैं। जावा की तरह C ++ लिखना खराब C ++ है, और C ++ की तरह जावा लिखना खराब जावा है।

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

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


2

जोड़ी एक अच्छा सामान होगी, एक जटिल जेनरिक के लिए एक बुनियादी निर्माण इकाई होगी, उदाहरण के लिए, यह मेरे कोड से है:

WeakHashMap<Pair<String, String>, String> map = ...

यह हास्केल के टपल के समान ही है


1
अब मैं कह सकता हूं, कि Pair <A, B> का उपयोग कोड को कम जानकारीपूर्ण बनाता है, और Pair का उपयोग करने के बजाय विशेष वस्तुओं को लागू करना ज्यादा बेहतर है
Illarion Kovalchuk

1
बेहतर या खराब। कल्पना कीजिए कि आपके पास इसके दो तर्कों (जैसे कि ग्राफ़ को एक में विलय करना) का फ़ंक्शन है और इसे कैश करने की आवश्यकता है। यहाँ, Pairइष्टतम है क्योंकि कोई विशेष शब्दार्थ नहीं है। एक स्पष्ट अवधारणा के लिए एक स्पष्ट नाम होना अच्छा है, लेकिन एक ऐसे नाम की तलाश है जहां "पहला" और "दूसरा" अच्छी तरह से काम नहीं करता है।
19art में maaartinus

2

सरल तरीका वस्तु [] - का उपयोग एई डिमेशन टपल के रूप में किया जा सकता है


2
किसी भी आयाम, हाँ। लेकिन: बोझिल बनाने के लिए, और प्रकार-सुरक्षित नहीं।
माइकल पीफेल

2

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

उदाहरण: http://www-igm.univ-mlv.fr/~lecroq/string/node8.html#SECTION0080

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

मैंने अपने पुस्तकालय में ऐसा कुछ किया है

public class Pair<First,Second>{.. }

2

आप Google की AutoValue लाइब्रेरी - https://github.com/google/auto/tree/master/value का उपयोग कर सकते हैं ।

आप एक बहुत छोटा सार वर्ग बनाते हैं और इसे @AutoValue के साथ एनोटेट करते हैं और एनोटेशन प्रोसेसर आपके लिए एक ठोस वर्ग उत्पन्न करता है जिसमें एक मूल्य शब्दार्थ होता है।


2

यहाँ कुछ पुस्तकालय हैं जो आपकी सुविधा के लिए कई डिग्री हैं:

  • JavaTuples । डिग्री 1-10 से ट्यूपल के पास यह सब है।
  • जावास्लैंग । डिग्री 0-8 से ट्यूपल और अन्य कार्यात्मक उपहारों के बहुत सारे।
  • jOOλ । 0-16 डिग्री और कुछ अन्य कार्यात्मक अच्छाइयों से ट्यूपल्स। (अस्वीकरण, मैं अनुरक्षक कंपनी के लिए काम करता हूं)
  • कार्यात्मक जावा । डिग्री 0-8 से ट्यूपल और अन्य कार्यात्मक उपहारों के बहुत सारे।

अन्य पुस्तकालयों में कम से कम Pairटपल शामिल होने का उल्लेख किया गया है ।

विशेष रूप से, कार्यात्मक प्रोग्रामिंग के संदर्भ में जो नाममात्र टाइपिंग ( जैसा कि स्वीकृत उत्तर में वकालत की जाती है ) के बजाय बहुत से संरचनात्मक टाइपिंग का उपयोग करता है , उन पुस्तकालयों और उनके ट्यूपल्स बहुत काम में आते हैं।


2

ब्रायन गोएट्ज़, पॉल सैंडोज़ और स्टुअर्ट मार्क्स बताते हैं कि देवॉक्सएक्स 14 में क्यूए सत्र के दौरान क्यों

मानक पुस्तकालय में सामान्य जोड़ी वर्ग होने से एक बार मूल्य प्रकार पेश किए जाने के बाद तकनीकी ऋण में बदल जाएगा ।

इसे भी देखें: क्या जावा एसई 8 में जोड़े या ट्यूपल हैं?


2

एक और क्रिया लोबोक कार्यान्वयन

import lombok.Value;

@Value(staticConstructor = "of")
public class Pair<F, S> {
    private final F first;
    private final S second;
}

1

मैंने देखा कि सभी जोड़ी कार्यान्वयन यहाँ चारों ओर बिखरे हुए हैं जो दो मूल्यों के क्रम के लिए विशेषता है। जब मैं एक जोड़ी के बारे में सोचता हूं, तो मैं दो वस्तुओं के संयोजन के बारे में सोचता हूं जिसमें दोनों के क्रम का कोई महत्व नहीं है। यहां संग्रह में वांछित व्यवहार सुनिश्चित करने के लिए एक अनियंत्रित जोड़ी का मेरा कार्यान्वयन hashCodeऔर equalsओवरराइड है। क्लोन करने योग्य भी।

/**
 * The class <code>Pair</code> models a container for two objects wherein the
 * object order is of no consequence for equality and hashing. An example of
 * using Pair would be as the return type for a method that needs to return two
 * related objects. Another good use is as entries in a Set or keys in a Map
 * when only the unordered combination of two objects is of interest.<p>
 * The term "object" as being a one of a Pair can be loosely interpreted. A
 * Pair may have one or two <code>null</code> entries as values. Both values
 * may also be the same object.<p>
 * Mind that the order of the type parameters T and U is of no importance. A
 * Pair&lt;T, U> can still return <code>true</code> for method <code>equals</code>
 * called with a Pair&lt;U, T> argument.<p>
 * Instances of this class are immutable, but the provided values might not be.
 * This means the consistency of equality checks and the hash code is only as
 * strong as that of the value types.<p>
 */
public class Pair<T, U> implements Cloneable {

    /**
     * One of the two values, for the declared type T.
     */
    private final T object1;
    /**
     * One of the two values, for the declared type U.
     */
    private final U object2;
    private final boolean object1Null;
    private final boolean object2Null;
    private final boolean dualNull;

    /**
     * Constructs a new <code>Pair&lt;T, U&gt;</code> with T object1 and U object2 as
     * its values. The order of the arguments is of no consequence. One or both of
     * the values may be <code>null</code> and both values may be the same object.
     *
     * @param object1 T to serve as one value.
     * @param object2 U to serve as the other value.
     */
    public Pair(T object1, U object2) {

        this.object1 = object1;
        this.object2 = object2;
        object1Null = object1 == null;
        object2Null = object2 == null;
        dualNull = object1Null && object2Null;

    }

    /**
     * Gets the value of this Pair provided as the first argument in the constructor.
     *
     * @return a value of this Pair.
     */
    public T getObject1() {

        return object1;

    }

    /**
     * Gets the value of this Pair provided as the second argument in the constructor.
     *
     * @return a value of this Pair.
     */
    public U getObject2() {

        return object2;

    }

    /**
     * Returns a shallow copy of this Pair. The returned Pair is a new instance
     * created with the same values as this Pair. The values themselves are not
     * cloned.
     *
     * @return a clone of this Pair.
     */
    @Override
    public Pair<T, U> clone() {

        return new Pair<T, U>(object1, object2);

    }

    /**
     * Indicates whether some other object is "equal" to this one.
     * This Pair is considered equal to the object if and only if
     * <ul>
     * <li>the Object argument is not null,
     * <li>the Object argument has a runtime type Pair or a subclass,
     * </ul>
     * AND
     * <ul>
     * <li>the Object argument refers to this pair
     * <li>OR this pair's values are both null and the other pair's values are both null
     * <li>OR this pair has one null value and the other pair has one null value and
     * the remaining non-null values of both pairs are equal
     * <li>OR both pairs have no null values and have value tuples &lt;v1, v2> of
     * this pair and &lt;o1, o2> of the other pair so that at least one of the
     * following statements is true:
     * <ul>
     * <li>v1 equals o1 and v2 equals o2
     * <li>v1 equals o2 and v2 equals o1
     * </ul>
     * </ul>
     * In any other case (such as when this pair has two null parts but the other
     * only one) this method returns false.<p>
     * The type parameters that were used for the other pair are of no importance.
     * A Pair&lt;T, U> can return <code>true</code> for equality testing with
     * a Pair&lt;T, V> even if V is neither a super- nor subtype of U, should
     * the the value equality checks be positive or the U and V type values
     * are both <code>null</code>. Type erasure for parameter types at compile
     * time means that type checks are delegated to calls of the <code>equals</code>
     * methods on the values themselves.
     *
     * @param obj the reference object with which to compare.
     * @return true if the object is a Pair equal to this one.
     */
    @Override
    public boolean equals(Object obj) {

        if(obj == null)
            return false;

        if(this == obj)
            return true;

        if(!(obj instanceof Pair<?, ?>))
            return false;

        final Pair<?, ?> otherPair = (Pair<?, ?>)obj;

        if(dualNull)
            return otherPair.dualNull;

        //After this we're sure at least one part in this is not null

        if(otherPair.dualNull)
            return false;

        //After this we're sure at least one part in obj is not null

        if(object1Null) {
            if(otherPair.object1Null) //Yes: this and other both have non-null part2
                return object2.equals(otherPair.object2);
            else if(otherPair.object2Null) //Yes: this has non-null part2, other has non-null part1
                return object2.equals(otherPair.object1);
            else //Remaining case: other has no non-null parts
                return false;
        } else if(object2Null) {
            if(otherPair.object2Null) //Yes: this and other both have non-null part1
                return object1.equals(otherPair.object1);
            else if(otherPair.object1Null) //Yes: this has non-null part1, other has non-null part2
                return object1.equals(otherPair.object2);
            else //Remaining case: other has no non-null parts
                return false;
        } else {
            //Transitive and symmetric requirements of equals will make sure
            //checking the following cases are sufficient
            if(object1.equals(otherPair.object1))
                return object2.equals(otherPair.object2);
            else if(object1.equals(otherPair.object2))
                return object2.equals(otherPair.object1);
            else
                return false;
        }

    }

    /**
     * Returns a hash code value for the pair. This is calculated as the sum
     * of the hash codes for the two values, wherein a value that is <code>null</code>
     * contributes 0 to the sum. This implementation adheres to the contract for
     * <code>hashCode()</code> as specified for <code>Object()</code>. The returned
     * value hash code consistently remain the same for multiple invocations
     * during an execution of a Java application, unless at least one of the pair
     * values has its hash code changed. That would imply information used for 
     * equals in the changed value(s) has also changed, which would carry that
     * change onto this class' <code>equals</code> implementation.
     *
     * @return a hash code for this Pair.
     */
    @Override
    public int hashCode() {

        int hashCode = object1Null ? 0 : object1.hashCode();
        hashCode += (object2Null ? 0 : object2.hashCode());
        return hashCode;

    }

}

इस कार्यान्वयन को ठीक से परीक्षण किया गया है और एक सेट और मानचित्र में उपयोग की कोशिश की गई है।

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


3
वास्तव में, प्रत्येक पृष्ठ के नीचे की जाँच करें: "cc-wiki के तहत लाइसेंस प्राप्त उपयोगकर्ता योगदान"
amara

आह, मैंने उस पर ध्यान नहीं दिया था। सर उठाने के लिए धन्यवाद। उस स्थिति में, कोड का उपयोग करें जैसा कि आप उस लाइसेंस के तहत फिट देखते हैं।
G_H

1
प्रश्न एक C ++ समकक्ष जोड़ी के बारे में है - जिसे आदेश दिया गया है। मुझे यह भी लगता है कि जब तक किसी के पास पेयर की वस्तु का संदर्भ है और वे संग्रह में जोड़े जाने योग्य हैं, तब तक अपरिभाषित व्यवहार हो सकता है।
Mr_and_Mrs_D


1

com.sun.tools.javac.util.Pair एक जोड़ी का एक सरल कार्यान्वयन है। यह jdk1.7.0_51 \ lib \ tools.jar में पाया जा सकता है।

Org.apache.commons.lang3.tuple.Pair के अलावा, यह सिर्फ एक इंटरफ़ेस नहीं है।


2
किसी को भी JDK आंतरिक APIs का उपयोग नहीं करना चाहिए।
jpangamarca

0
public class Pair<K, V> {

    private final K element0;
    private final V element1;

    public static <K, V> Pair<K, V> createPair(K key, V value) {
        return new Pair<K, V>(key, value);
    }

    public Pair(K element0, V element1) {
        this.element0 = element0;
        this.element1 = element1;
    }

    public K getElement0() {
        return element0;
    }

    public V getElement1() {
        return element1;
    }

}

उपयोग:

Pair<Integer, String> pair = Pair.createPair(1, "test");
pair.getElement0();
pair.getElement1();

अपरिवर्तनीय, केवल एक जोड़ी!


ओह वाह। और एक? अधिक जटिल जेनरिक के साथ आपका उपयोग करने का प्रयास करें - कुछ बिंदु पर, यह उपयुक्त प्रकारों का अनुमान लगाने में विफल होगा। इसके अलावा, निम्नलिखित संभव होना चाहिए: Pair<Object, Object> pair = Pair.createPair("abc", "def")लेकिन मुझे Pair.createPair((Object)"abc", (Object)"def")आपके कोड के साथ लिखने की आवश्यकता है ?
QUIT है - Anony-Mousse

आप इसके द्वारा स्थैतिक विधि को प्रतिस्थापित कर सकते हैं: @SuppressWarnings("unchecked") public static <K, V, X, Y> Pair<X, Y> createPair(K key, V value) { return new Pair<X, Y>((X) key, (Y) value); } लेकिन मुझे नहीं पता कि यह एक अच्छा अभ्यास है
Bastiflew

नहीं, यह संभवत: केवल चीजों को और अधिक खराब कर देगा। मेरे अनुभव में, कम से कम एक कंपाइलर (कोशिश java6, java7, javadoc और eclipse java compiler) करेंगे। new Pair<Object, Object>("abc", "def")मेरे प्रयोगों में पारंपरिक सबसे विश्वसनीय था।
Anony-मूस - QUIT है
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.