Каков наилучший способ вернуть пару значений в Java?

Это небольшая проблема, так как я мог легко взломать class пары, чтобы выполнить эту работу. Я действительно не хочу этого делать, и я чувствую, что должен быть простой, встроенный, похожий на Java способ возврата двух значений. Что вы, ребята, лучший и самый простой способ сделать это? Массивы? Некоторая другая структура данных?

Насколько мне известно, к сожалению, нет встроенного представления пары в Java (и я, конечно, хотел бы, чтобы она была). Лично, когда я кодирую проект, где я нахожу, что парный class часто был бы полезен, я создаю общий class Pair (что, вероятно, то, о чем вы думали). Возrotation массива является быстрым и простым способом, но позже вы можете пожалеть об этом, потому что люди, которые используют ваш метод, задаются вопросом, может ли метод в какой-то момент вернуть более двух значений.

Какое бы решение вы ни выбрали: всякий раз, когда вы чувствуете, что вам нужна пара, вы должны подумать о том, стоит ли экономить время, используя, например, общий class Pair, ценность потери информации для следующего человека, который читает код (и этот человек может хорошо будь вы через шесть месяцев). Написание отдельного classа для типа возвращаемого значения занимает больше времени, но оно будет передавать больше информации тем, кто использует ваш метод (а именно, он сообщает пользователям, что представляет собой возвращаемое значение, и содержит полезные имена участников для двух значений). Если это непубличный метод, который используется только в нескольких местах, хотя пара более приемлема.

Использование classа контейнера – самый простой способ.

  public class Pair { public final T t; public final U u; public Pair(T t, U u) { this.t= t; this.u= u; } } 

Самое близкое, что я видел к «паре» в стандартных библиотеках, это интерфейс Map.Entry и classы AbstractMap.SimpleEntry и AbstractMap.SimpleImmutableEntry которые его реализуют.

Если оба объекта являются одним и тем же classом, массив проще в использовании.

Apache Commons Lang3 предоставляет абстрактный class Pair с несколькими реализациями, включая ImmutablePair и MutablePair.

Три подхода, все не так велики:

  1. Сверните свою Pair . Вы сказали, что не хотите этого делать.
  2. Вернуть Object[] . Это не безопасный тип.
  3. Мимические переменные или указатели , поставляя массивы одиночных элементов в качестве параметров.

Пример № 3:

 public boolean getUserDetails(String userId, String[] lastName, String[] firstName, Date[] dob) { assert lastName != null && lastName.length == 1; assert firstName != null && firstName.length == 1; assert dob != null && dob.length == 1; ... } 

Третий вариант делает жизнь болезненной для вызывающего.

Так что, как я уже сказал, никакого приятного решения.

В стороне, Scala использует различные classы Tuple (до 21 кортежа, из того, что я помню), чтобы помочь вам в этом.

если оба являются целыми числами, то я бы посоветовал java.awt.Point, но в остальном просто создаю контейнерный class с двумя объектами x и y

Мне сказали эксперты, что, столкнувшись с вопросом о парах, одна из двух вещей верна:

  1. Вам нужно переосмыслить свою структуру (этот тупой ответ никому не помогает)
  2. Вам нужно создать собственный class для хранения пары

Я бы предположил, что второй случай не является настолько ненормальным. Однако, если то, что вы делаете, кажется слишком тривиальным для введения нового classа, то использование Map может работать, как и другие. Если вы просто отправляете один ответ назад, то Map кажется немного.

Если список пар звучит так, как будто он работает, и вам нужно поддерживать порядок, вы можете попробовать LinkedHashMap , чтобы поддерживать порядок.

Некоторые мои наблюдения:

  1. Массив является пугающим, быстрым и простым в использовании, хотя и невозможным для расширения его возможностей. Что делать, если вы хотите вернуть 3 значения через 3 месяца?

  2. ArrayList / другие colletions могут быть хорошими, позволяет увеличить емкость (изначально 10). Обратите внимание, что Vector может быть излишним по сравнению с ArrayList, когда вы хотите сохранить только 2 значения, которые будут выбраны позже. Карта также может быть хорошей, потому что она всегда сортируется и упорядочивается.

  3. Определенный пользовательский class: возможно, опция if имеет смысл (означает, что возвращаемые данные важны, а именно, как Java-Bean), и вы хотите сохранить в нем не более двух целых чисел. Читаемость лучше, если вы добавите в свой Javadoc больше заметок. Может быть расширен, как вам нравится, просто добавьте поля в этот class. Медленно, но безопаснее.

В JavaFX есть пара classов, но вы не должны его использовать. То, что вы ДОЛЖНЫ использовать, выглядит примерно так:

 // We've skipped imports and package declarations public final class YourClass { /* Assume there is a bunch of stuff here */ // I don't know what method you're using, so forgive the silly example public YourClass.Pair sillyExampleOfPairs(String someString) { return new YourClass.Pair(someString, someString.length() * 13); } @Value // Lombok annotation. public static class Pair { String text; int integer; } // this is an even more succinct possibility @Value public static final class ShorterPair {String text; int integer} } 

Хотя имя «Пара» здесь явно не так хорошо выбрано, и вы должны выбрать более описательное имя, очевидные способы его работы (поля являются окончательными частными и у вас есть геттер для каждого из-за annotations), не должно быть потерянный на вас. И хотя да, это немного более многословие, чем использование пары, это гораздо более надежное. Что делать, если вам нужно добавить дополнительный параметр к возвращаемому значению? Вы «только» должны изменить этот class. И вы можете сразу обновить все соответствующие JavaDocs, что тоже приятно. Если вам нужно менять типы, они оба повлекут за собой аналогичную работу.

Пока вы только добавляете материал, старые методы getText () и getInteger () будут работать так же, как и раньше. Вы также избегаете добавлять к своим проектам еще одну зависимость. Это не большая победа. Наличие пары доступно для прототипирования, но это не приятно.

Мой последний теоретический аргумент CS-y состоит в том, что Pair – это тот же тип, что и Pair. Но если у вас есть Phonebook.Entry (с String и int) и скажите, Inventory.Item (с именем и рядом элементов, которые мы в настоящее время инвентаризировали), эти два очень разных типа, которые делают очень разные вещи. Вы не можете поместить один в другой. Это хорошая вещь.

Нам также намного яснее для нас, бедных ублюдков, которым нужно идти и отлаживать свои системы, чтобы увидеть что-то вроде «com.name.project.something.something.Phonebook.Entry» в трассировке стека, чем «org.apache.commons.lang3.tuple .Pair». Один из них говорит мне, на что я должен смотреть, и дает мне информацию о том, ПОЧЕМУ Я вижу пару. Другой говорит … ничего.

Теперь вам может быть безразлично, что вам нужно набрать еще 3 секунды, чтобы сэкономить мне 3 минуты. Но я предпочитаю верить в доброту твоего сердца и благородство твоей души. Поэтому поступайте правильно.

Вместо этого напишите небольшой статический class.