UPDATE: Jawaban ini sebagai tanggapan terhadap pertanyaan awal, Apakah Java SE 8 memiliki Pasangan atau Tuple? (Dan secara implisit, jika tidak, mengapa tidak?) OP telah memperbarui pertanyaan dengan contoh yang lebih lengkap, tetapi sepertinya itu dapat diselesaikan tanpa menggunakan struktur Pair. [Catatan dari OP: inilah jawaban yang benar .]
Jawaban singkatnya adalah tidak. Anda harus menggulung sendiri atau membawa salah satu dari beberapa perpustakaan yang mengimplementasikannya.
Memiliki Pair
kelas di Jawa SE diusulkan dan ditolak setidaknya sekali. Lihat utas diskusi ini di salah satu milis OpenJDK. Pengorbanannya tidak jelas. Di satu sisi, ada banyak implementasi Pair di perpustakaan lain dan dalam kode aplikasi. Itu menunjukkan kebutuhan, dan menambahkan kelas seperti itu ke Java SE akan meningkatkan penggunaan kembali dan berbagi. Di sisi lain, memiliki kelas Pair menambah godaan untuk menciptakan struktur data yang rumit dari Pasangan dan koleksi tanpa membuat jenis dan abstraksi yang diperlukan. (Itu adalah parafrase dari pesan Kevin Bourillion dari utas itu.)
Saya sarankan semua orang membaca seluruh utas email itu. Ini sangat berwawasan dan tidak memiliki kerusakan. Cukup meyakinkan. Ketika mulai, saya berpikir, "Ya, seharusnya ada kelas Pair di Java SE" tetapi pada saat thread mencapai akhirnya saya telah berubah pikiran.
Perhatikan bahwa JavaFX memiliki kelas javafx.util.Pair . API JavaFX berevolusi secara terpisah dari Java SE API.
Seperti yang dapat dilihat dari pertanyaan terkait Apa persamaan dari C ++ Pair in Java? ada ruang desain yang cukup besar di sekitar apa yang tampaknya seperti API sederhana. Haruskah benda tidak berubah? Haruskah mereka serial? Haruskah mereka sebanding? Haruskah kelasnya final atau tidak? Haruskah kedua elemen dipesan? Haruskah itu antarmuka atau kelas? Mengapa berhenti berpasangan? Mengapa tidak tiga kali lipat, paha depan, atau N-tupel?
Dan tentu saja ada penamaan yang tak terhindarkan bikeshed untuk elemen:
- (a, b)
- (pertama kedua)
- (kiri kanan)
- (mobil, cdr)
- (foo, bar)
- dll.
Satu masalah besar yang hampir tidak disebutkan adalah hubungan Pasangan dengan primitif. Jika Anda memiliki (int x, int y)
datum yang mewakili titik dalam ruang 2D, mewakili ini sebagai Pair<Integer, Integer>
mengkonsumsi tiga objek, bukan dua kata 32-bit. Selanjutnya, benda-benda ini harus berada di heap dan akan dikenakan overhead GC.
Tampak jelas bahwa, seperti Streams, penting untuk ada spesialisasi primitif untuk Pasangan. Apakah kita ingin melihat:
Pair
ObjIntPair
ObjLongPair
ObjDoublePair
IntObjPair
IntIntPair
IntLongPair
IntDoublePair
LongObjPair
LongIntPair
LongLongPair
LongDoublePair
DoubleObjPair
DoubleIntPair
DoubleLongPair
DoubleDoublePair
Bahkan sebuah IntIntPair
masih akan membutuhkan satu objek di heap.
Ini, tentu saja, mengingatkan pada proliferasi antarmuka fungsional dalam java.util.function
paket di Java SE 8. Jika Anda tidak ingin API kembung, yang mana yang akan Anda tinggalkan? Anda juga bisa berpendapat bahwa ini tidak cukup, dan bahwa spesialisasi untuk, katakanlah, Boolean
harus ditambahkan juga.
Perasaan saya adalah bahwa jika Java telah menambahkan kelas Pair sejak lama, itu akan menjadi sederhana, atau bahkan sederhana, dan itu tidak akan memuaskan banyak kasus penggunaan yang kita bayangkan sekarang. Pertimbangkan bahwa jika Pair telah ditambahkan dalam kerangka waktu JDK 1.0, itu mungkin akan bisa berubah! (Lihatlah java.util.Date.) Apakah orang akan senang dengan itu? Dugaan saya adalah bahwa jika ada kelas Pair di Jawa, itu akan menjadi semacam-agak-tidak-benar-berguna dan semua orang masih akan bergulir sendiri untuk memenuhi kebutuhan mereka, akan ada berbagai implementasi Pair dan Tuple di perpustakaan eksternal, dan orang-orang masih akan berdebat / berdiskusi tentang cara memperbaiki kelas Pasangan Jawa. Dengan kata lain, jenis di tempat yang sama kita di hari ini.
Sementara itu, beberapa pekerjaan sedang berlangsung untuk mengatasi masalah mendasar, yang merupakan dukungan yang lebih baik dalam JVM (dan akhirnya bahasa Jawa) untuk tipe nilai . Lihat dokumen Status Nilai ini . Ini adalah pekerjaan pendahuluan dan spekulatif, dan hanya membahas masalah dari perspektif JVM, tetapi sudah ada cukup banyak pemikiran di baliknya. Tentu saja tidak ada jaminan bahwa ini akan masuk ke Java 9, atau pernah masuk ke mana saja, tetapi hal itu menunjukkan arah pemikiran saat ini tentang topik ini.
AbstractMap.SimpleImmutableEntry<K,V>
selama bertahun-tahun ... Tapi bagaimanapun, bukannya pemetaani
untuk(i, value[i])
hanya untuk menyaring olehvalue[i]
dan pemetaan kembali kei
: mengapa tidak hanya filter byvalue[i]
di tempat pertama, tanpa pemetaan?