Если я понял ваши намерения, то правильный способ создания getFooXxx
для создания неизменяемой копии возможно-изменяемого списка выглядит примерно так:
/**
* Returns an <b>immutable copy</b> of input list.
*/
public ImmutableList<Foo> immutableCopyOfFoo(List<Foo> input){
return ImmutableList.copyOf(input);
}
Почему?
ImmutableList.copyOf()
делает магию , когда данный список неизменен,
- подпись метода явно говорит о том, что он делает,
- метод возвращает
ImmutableList
, который является , на самом деле ImmutableCollection
, но почему вы хотите скрыть информацию о ImmutableList
от пользователя? Если он хочет, он вместо этого напишет Iterable foo = immutableCopyOfFoo(mutableFoo);
, но на 99% он будет использовать ImmtableList,
- возвращая
ImmutableList
дает обещание - «Я неизменен, и я все взорву, если вы попытаетесь изменить меня!»
и последнее, но не менее важное - предлагаемый метод не нужен для внутреннего использования; просто используйте
someOtherMethod(ImmutableList.copyOf(foo));
прямо в вашем коде ...
Вы должны проверить @ ответ ChrisPovirk (и ссылку на вики в этом ответе), чтобы знать, что, например, когда List<Foo> input
содержит null
s, вы получите неприятный NPE во время выполнения, если попытаетесь неизменная копия ...
РЕДАКТИРОВАТЬ ответ на комментарий № 1:
Collection
контракт менее строг, чем List
контракт; т.е. коллекция не гарантирует какой-либо порядок элементов («некоторые упорядочены, а другие неупорядочены»), в то время как List это делает («упорядоченная коллекция (также известная как последовательность)»).
Если вход представляет собой Список , это говорит о том, что порядок важен, и поэтому выходные данные должны гарантировать то же самое. Представьте себе, что:
public ImmutableCollection<Foo> immutableCopyOfFoo(List<Foo> input){
return ImmutableSortedSet.copyOf(input, someFancyComparator);
}
Это не пахнет правильно. Если вас не интересует порядок, возможно, подпись метода должна быть immutableCopyOfFoo(Collection<Foo> input)
? Но это зависит от конкретного варианта использования.