19

List<Foo> getFoos ()リモートサーバーからデータを取得して返すメソッドがあります。

もちろん、ユーザーはサーバー上のデータと同期されていないデータを取得するため、リストのアイテム数を変更しないでください（アイテム数を変更したい場合は、のような特別なメソッドがありますaddFoo ()）。

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

Collections.unmodifiableList (originalList)

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

同様の場合のAPI設計に関する推奨事項はありますか？

4

5 に答える 5

25

Collections.unmodifiableList完全に受け入れられ、より高速になるはずです（配列を作成する必要はありません）。

編集 - API 設計に関しては、JavaDoc を明確にする必要があります。ドキュメントを読まずにメソッドを使用する人は驚くに値します :p

于 2010-02-02T17:14:17.920 に答える
2

また、配列を返すよりも完全に受け入れられ、はるかに優れていると思います（これは、完全に非推奨の型として扱われるべきであると示唆する人もいます）。ただし、APIでそれについてより明確にしたい場合は、GoogleコレクションImmutableListからを返すことを検討できます。

于 2010-02-02T17:20:39.323 に答える
1

裸のリストや配列を返すことは事実上ありません。何かのコレクションがある場合、ほとんどの場合、そのコレクションの一部であるはずのコードがどこかに関連付けられています。コレクションの周りにクラスがないため、コレクションが使用されているさまざまな場所でそのコードを複製する必要があります。

また、通常、コレクションに関連付けられている変数が 1 つまたは 2 つあります。コレクションを渡すたびに、それらを渡すことがわかります。これらは、コレクションをラップするビジネス ロジック クラスに属します。

于 2010-02-02T17:32:17.680 に答える
0

完全な自由があり、そう思われる場合は、配列またはリストのどちらかを選択する必要はなく、イテレータを返す必要があります。これは、一意性が必要な場合にも役立ちます。 Set を返す代わりに、イテレータを返します。

于 2010-03-08T20:42:31.070 に答える
0

既存のオブジェクトからカスタムの特殊なプロパティが必要な場合、またはこの場合は List が必要な場合は、それを拡張または格納して、関連するアクセサーが例外をスローするようにしてみませんか?

その理由は、他のクライアント オブジェクトがリストを変更できるようにしたい場合があるためです。返されるデータがアプリケーション レベルにどれだけ近いかによって異なります。

于 2010-02-02T17:16:10.517 に答える