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