Допустимо ли возвращать unmodifiableList или я должен возвращать массив?

У меня есть метод List<Foo> getFoos (), который получает данные с удаленного сервера и возвращает его.

Конечно, пользователь не должен изменять количество элементов списка, потому что он получит данные, не синхронизированные с данными на сервере (и если он хочет изменить количество элементов, у него есть специальные методы, такие как addFoo ()).

Первый подход состоял в том, чтобы вернуть массив и заменить подпись метода на Foo[] getFoos (). Но он более распространен в java и более удобен для пользователя для работы с коллекциями, поэтому я заменил подпись на List<Foo> getFoos (). Этот метод всегда возвращает

Collections.unmodifiableList (originalList)

Итак, когда пользователь пытается изменить список, он получит RuntimeException.

Есть ли какие-либо рекомендации по дизайну api в подобных случаях?

Ответ 1

Collections.unmodifiableList является совершенно приемлемым и должен быть быстрее (нет необходимости создавать массив).

Изменить. Что касается дизайна API, вы должны просто очистить свой JavaDoc! Люди, которые используют метод без чтения своего документа, заслуживают удивления: p

Ответ 2

Я бы также сказал, что это вполне приемлемо и намного лучше, чем возврат массива (который некоторые предлагают рассматривать как устаревший тип в целом). Если вы хотите более подробно описать это в API, вы можете рассмотреть возможность возврата ImmutableList из Коллекции Google.

Ответ 3

Я практически никогда не возвращаю голый список или массив. Если у вас есть коллекция чего-то, у нее почти всегда есть какой-то код, связанный с ним, который должен быть частью этой коллекции. Не имея класса вокруг коллекции, вы заставляете себя дублировать этот код в разных местах, где используется коллекция.

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

Ответ 4

Если вы хотите создать специализированное специализированное свойство из существующего объекта или List в этом случае, почему бы не попробовать его расширять или содержать, и сделать соответствующие аксессоры для исключения?

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

Ответ 5

Если у вас есть полная свобода, и, похоже, вы это делаете, вам не нужно выбирать между массивом или списком, а скорее возвращать итератор. Это также поможет, если вам нужна уникальность, вместо того, чтобы возвращать Set - все равно возвращать итератор.