unmodifiableList を返すことは許容されますか、それとも配列を返す必要がありますか?

Question

私には方法があります List<Foo> getFoos () リモートサーバーからデータを取得して返します。

もちろん、ユーザーはサーバー上のデータと同期していないデータを取得するため、リストの項目数を変更すべきではありません (項目数を変更したい場合は、次のような特別なメソッドがあります) addFoo ()).

最初のアプローチは、配列を返し、メソッドのシグネチャを次のように変更することでした。 Foo[] getFoos (). 。しかし、Javaではより一般的であり、ユーザーにとってコレクションを操作する方が便利なので、署名を次のように変更しました。 List<Foo> getFoos (). 。このメソッドは常に返します

Collections.unmodifiableList (originalList)

したがって、ユーザーがリストを変更しようとすると、RuntimeException が発生します。

同様のケースにおける API 設計に関する推奨事項はありますか?

Answer 1

完全に許容され、高速でなければならないのCollections.unmodifiableList（アレイを作成する必要はありません）。

編集 - APIデザインの面では、あなたは自分のJavaDocを明確にする必要があります！そのドキュメントを読まずにメソッドを使用する人々は驚きに値する：P

Answer 2

また、それは完全に許容でき、配列を返すよりもはるかに優れているとも言えます（ いくつかの 完全に非推奨のタイプとして扱う必要があることを示唆しています)。ただし、API でそれについてより明示的にしたい場合は、 ImmutableList から Google コレクション.

Answer 3

私は、事実上裸リストや配列を返すことはありません。あなたが何かのコレクションを持っている場合、それはほとんど常にそのコレクションの一部である必要があり、それに関連するいくつかのコードのどこかにあります。コレクションを中心にクラスを持っていないことによって、あなたは、コレクションが使用されている別の場所間でそのコードを複製するために自分自身を迫られています。

もあり、一般的に、コレクションに関連付けられている変数または2。あなたは、コレクションを渡すたびにそれらを渡す見つけることができます。これらのコレクションをラップビジネスロジッククラスます。

で属し

Answer 4

カスタムをしたい場合は、拡張しようとしたり、それが含まれていると、例外をスローするように、関連するアクセサをしないで、なぜこのような場合には既存のオブジェクト、またはリストからプロパティを専門に？

あなたには、いくつかの他のクライアントオブジェクトがリストを変更することを可能にすることを望むかもしれないので、

は理由があります。それはアプリケーションレベルに近いが、返されたデータであるかによって異なります。

Answer 5

あなたは完全な自由を持っているし、あなたが、あなたは、配列またはリストの間で選択する必要はありませんないと思われる場合は、

、むしろ反復子を返します。これはまた、ヘルプには、あなたがそう代わりにセットを返すの一意性が必要な場合でしょう - まだイテレータを返す。

。