Я проголосовал за ваш принятый ответ и согласен с ним - однако могу ли я дать вам кое-что рассмотреть?
Не возвращайте коллекцию напрямую. Создайте класс бизнес-логики с точным именем, который отражает цель коллекции.
Основным преимуществом этого является то, что вы не можете добавлять код в коллекции, поэтому, когда у вас есть собственная «коллекция» в вашей объектной модели, вы ВСЕГДА имеете не-OO-код поддержки, распространяющийся по всему проекту для доступа к нему. .
Например, если бы ваша коллекция была счетами, у вас, вероятно, было бы 3 или 4 места в вашем коде, где вы просматривали неоплаченные счета. Вы можете иметь метод getUnpaidInvoices. Однако настоящая сила приходит, когда вы начинаете думать о таких методах, как «payUnpaidInvoices (payer, account);».
Когда вы передаете коллекции вместо написания объектной модели, вам никогда не придет в голову целый класс рефакторинга.
Обратите внимание, что это делает вашу проблему особенно приятной. Если вы не хотите, чтобы люди меняли коллекции, ваш контейнер не должен содержать мутаторов. Если позже вы решите, что только в одном случае вам действительно нужно его изменить, вы можете создать безопасный механизм для этого.
Как вы решаете эту проблему, когда передаете нативную коллекцию?
Кроме того, собственные коллекции не могут быть расширены за счет дополнительных данных. Вы узнаете это в следующий раз, когда обнаружите, что передаете (Collection, Extra) более чем одному или двум методам. Это означает, что «Extra» принадлежит объекту, содержащему вашу коллекцию.