Лучше использовать список пар или два списка?

Создайте метод обратной передачи Ajax, который пишет файл CSV в Ваш веб-сервер и возвращает URL.. Установите скрытый IFrame в браузере к местоположению файла CSV на сервере.

Вашему пользователю тогда подарят ссылку на загрузку CSV.

6
задан Andrzej Doyle 22 September 2009 в 08:31
поделиться

11 ответов

Я бы настоятельно рекомендовал связать эти данные вместе, возможно, как пару, но больше как конкретный контейнер. Таким образом, вы можете ввести дополнительную функциональность, связанную с этими двумя объектами.

Хранение двух списков по отдельности будет проблемой. Вам придется передавать оба вместе и синхронизировать их. Накладные расходы на создание нового объекта для этого незначительны, и именно для этого предназначено ООП (вы будете создавать классы, отличные от JDK, просто написав новый код Java для своего приложения, не забывайте).

Я создаю второстепенные классы любят это все время. Они обеспечивают строгую безопасность типов и предоставляют возможности для улучшения и рефакторинга. IDE могут более легко идентифицировать и выполнять рефакторинг.

23
ответ дан 8 December 2019 в 02:19
поделиться

Почему бы не использовать Словарь (тип карты, как бы Java ни называла его в настоящее время, я думаю, что раньше это было ] Хеш-таблица )? Это позволит сопоставить идентификаторы со значениями и обойти вашу дилемму.

5
ответ дан 8 December 2019 в 02:19
поделиться

Я бы выбрал Список из пар , если два целых числа действительно принадлежат друг другу и должны представлять «одно».

Еще одним недостатком использования двух отдельных списков является то, что компилятор не проверяет, всегда ли списки одного размера. И вы оставляете интерпретацию на усмотрение клиента вашего метода; клиенту необходимо сопоставить элементы в двух списках.

Я не считаю использование класса типа Pair большим недостатком, «потому что он полагается на классы, не относящиеся к JDK», как вы говорите , но если вы действительно не хотите использовать что-то вроде Pair , вы даже можете сделать его списком массивов: List , где каждый массив содержит два Целочисленные объекты.

2
ответ дан 8 December 2019 в 02:19
поделиться

Когда API является общедоступным, убедитесь, что вы реализуете только основные функции, потому что все, что вы даете клиенту, никогда не может быть возвращено.

Подумайте о методе с назначением всего 2 параметров (целое число entityId, Integer someOtherId) и позвольте клиенту выяснить, как добавить больше элементов.

Если вы хотите разрешить удобный доступ, дайте им класс util, который поставляется с интерфейсом «Assignment», который просто определяет getEntityId () и getSomeOtherId ( ) и с реализацией по умолчанию, такой как DefaultAssignment, которая содержит окончательные ссылки на идентификаторы.

Затем ваши клиенты могут выбирать, каким путем они хотят идти, и вам не нужно обязательно поддерживать свой класс «Pair».

2
ответ дан 8 December 2019 в 02:19
поделиться

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

Я также склоняюсь к использованию пары класс, сославшись на перечисленные вами преимущества:

  • Более точно отражает реальную отношения между объектами
  • Устраняет некоторые классы динамических ошибка (например, несоответствие длины списка)

Самым большим для меня было бы первое.

Всегда пишите код, который демонстрирует намерение. Не программируйте, думая исключительно о реализации.

Использование класса типа Pair показывает намерение, что существует пара значений, которая представляет идентификатор и саму сущность. Он также показывает, что один объект Pair - это одна дискретная единица данных, которую необходимо обрабатывать вместе - то, что не может быть получено из двух отдельных List идентификаторов и объектов.

5
ответ дан 8 December 2019 в 02:19
поделиться

Подход со списком пар - очевидная вещь, поскольку он более точно отражает намерение, но карта может быть даже лучше, если идентификаторы уникальны.

Если у вас есть ] миллионов этих пар, и потребление памяти становится основным соображением, вы можете переключиться на пары списков (поскольку в каждой паре будет на один объект меньше).

2
ответ дан 8 December 2019 в 02:19
поделиться

Я наполовину не согласен с этим:

  • Не полагается на какие-либо классы, не относящиеся к JDK (просто, как пара для понимания концепции)

, потому что, хотя и не существует класса Pair в JDK есть интерфейс: Map.Entry , который соответствует вашему предполагаемому использованию в качестве ассоциации ключ / значение.

1
ответ дан 8 December 2019 в 02:19
поделиться

На мой взгляд, используйте список пар (или ваш собственный, более конкретный контейнер), поскольку он, кажется, наиболее естественно отражает проблему, которую вы решаете. И это только одна переменная, которую нужно отслеживать и отправлять в методы, а не две.

0
ответ дан 8 December 2019 в 02:19
поделиться

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

0
ответ дан 8 December 2019 в 02:19
поделиться

Вы можете подумать о том, чтобы сделать параметр Итератором . Если у вызывающего класса есть List , получение итератора тривиально. В противном случае создание итератора может быть проще, быстрее и / или естественнее. В некоторых случаях это может даже помочь устранить проблемы нехватки памяти.

0
ответ дан 8 December 2019 в 02:19
поделиться

Используйте список пар или карту.

Я не покупаю ни один из аргументов "против" вы перечислили.

Вы всегда должны ошибаться в сторону большей абстракции. Вы пишете объектно-ориентированный язык, а инкапсуляция и скрытие информации на мой взгляд, самая главная причина мыслить предметами. Он скрывает детали реализации от пользователей, позволяя им сосредоточиться на том, что предоставляет ваш класс. Они могут забыть о том, как ваш класс выполняет то, что они хотят. Вынуждая ваших клиентов вести два списка, вы просите их знать больше, чем им нужно.

0
ответ дан 8 December 2019 в 02:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: