У меня есть метод List<Foo> getFoos (), который получает данные с удаленного сервера и возвращает его.
Конечно, пользователь не должен изменять количество элементов списка, потому что он получит данные, не синхронизированные с данными на сервере (и если он хочет изменить количество элементов, у него есть специальные методы, такие как addFoo ()).
Первый подход состоял в том, чтобы вернуть массив и заменить подпись метода на Foo[] getFoos (). Но он более распространен в java и более удобен для пользователя для работы с коллекциями, поэтому я заменил подпись на List<Foo> getFoos (). Этот метод всегда возвращает
Collections.unmodifiableList (originalList)
Итак, когда пользователь пытается изменить список, он получит RuntimeException.
Есть ли какие-либо рекомендации по дизайну api в подобных случаях?
Collections.unmodifiableList является совершенно приемлемым и должен быть быстрее (нет необходимости создавать массив).
Изменить. Что касается дизайна API, вы должны просто очистить свой JavaDoc! Люди, которые используют метод без чтения своего документа, заслуживают удивления: p
Я бы также сказал, что это вполне приемлемо и намного лучше, чем возврат массива (который некоторые предлагают рассматривать как устаревший тип в целом). Если вы хотите более подробно описать это в API, вы можете рассмотреть возможность возврата ImmutableList из Коллекции Google.
Я практически никогда не возвращаю голый список или массив. Если у вас есть коллекция чего-то, у нее почти всегда есть какой-то код, связанный с ним, который должен быть частью этой коллекции. Не имея класса вокруг коллекции, вы заставляете себя дублировать этот код в разных местах, где используется коллекция.
Существует также, как правило, переменная или две, которые связаны с коллекцией. Вы обнаружите, что проходите их каждый раз, когда вы передаете коллекцию. Они относятся к классу бизнес-логики, который обертывает коллекцию.
Если вы хотите создать специализированное специализированное свойство из существующего объекта или List в этом случае, почему бы не попробовать его расширять или содержать, и сделать соответствующие аксессоры для исключения?
Причина в том, что вы можете разрешить некоторым другим объектам клиента изменять список; это зависит от того, насколько близки к уровню приложения возвращенные данные.
Если у вас есть полная свобода, и, похоже, вы это делаете, вам не нужно выбирать между массивом или списком, а скорее возвращать итератор. Это также поможет, если вам нужна уникальность, вместо того, чтобы возвращать Set - все равно возвращать итератор.