是否可以返回 unmodifyingList 还是应该返回数组?
我有方法 List
从远程服务器获取数据并返回。
当然,用户不应该更改列表的项目数量,因为他将获得与服务器上的数据不同步的数据(如果他想更改项目数量,他有特殊的方法,例如 addFoo ()
)。
第一种方法是返回数组并将方法的签名更改为 Foo[] getFoos () 。但它在java中更常见,并且用户操作集合更方便,所以我将签名更改为 List
Collections.unmodifyingList (originalList)
因此,当用户尝试更改列表时,他将得到 RuntimeException。
类似案例的api设计有什么建议吗?
I have method List<Foo> getFoos ()
which gets the data from remote server and returns it.
Of course, user shouldn't change number of items of the list because he'll get data not synchronized with data on the server (and if he want change number of items he has special methods like addFoo ()
).
First approach was to return array and change method's signature to Foo[] getFoos ()
. But it's more common in java and more convenient to user to operate with collections so I changed signature to List<Foo> getFoos ()
. This method always returns
Collections.unmodifiableList (originalList)
So, when user try to change the list he will get RuntimeException.
Are there any recommendations about api design in similar cases?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
<代码> Collections.unmodifyingList 是完全可以接受的,并且应该更快(不需要创建数组)。
编辑 - 在 API 设计方面,你应该让你的 JavaDoc 清晰!不阅读文档而使用方法的人应该感到惊讶:p
Collections.unmodifiableList
is perfectly acceptable and should be faster (no need to create an array).Edit - In terms of API design, you should just make your JavaDoc clear! People who use a method without reading its doc deserve the surprise :p
我还想说这是完全可以接受的,并且比返回数组要好得多(一些建议应该是完全被视为已弃用的类型)。但是,如果您想在 API 中更明确地了解它,您可以考虑从 Google 收藏集。
I'd also say it is perfectly acceptable and much better than returning an array (which some suggest should be treated as a deprecated type altogether). If you want to be more explicit about it in the API however, you could consider returning an
ImmutableList
from Google Collections.我几乎从不返回裸列表或数组。如果您有某个东西的集合,它几乎总是在某个与其关联的地方有一些代码,这些代码应该是该集合的一部分。如果没有围绕集合的类,您将强迫自己在使用集合的不同位置复制该代码。
通常,还有一个或两个与集合相关联的变量。每当您通过该集合时,您都会发现您通过了它们。它们属于包装该集合的业务逻辑类。
I virtually never return a naked list or array. If you have a collection of something, it nearly always has SOME code somewhere associated with it that should be a part of that collection. By not having a class around the collection you are forcing yourself to duplicate that code across different places where the collection is used.
There is also, generally, a variable or two that are associated with the collection. You'll find you pass them whenever you pass the collection. These belong in the business logic class that wraps the collection.
如果您想要来自现有对象的自定义、专用属性,或者在这种情况下为 List,为什么不尝试扩展或包含它并使相关访问器抛出异常呢?
原因是因为您可能希望允许其他一些客户端对象修改该列表;这取决于返回的数据与应用程序级别的接近程度。
If you want a custom, specialized property from an existing object, or List in this case why not try extending or contain it and make the relevant accessors to throw an exception?
The reason is because you may wish to allow some other client objects to modify the list; it depends on how close to the application level is the returned data.
如果您拥有完全的自由并且看起来确实如此,那么您不必在数组或列表之间进行选择,而是返回一个迭代器。如果您需要唯一性,那么这也会有所帮助,而不是返回 Set - 仍然返回迭代器。
If you have complete freedom and it seems you do, then you should not have to choose between array or List, rather return an iterator. This would also help if you need uniqueness so instead of returning Set - still return iterator.