为什么Java List接口不支持getLast()? [英] Why does the Java List interface not support getLast()?

问题描述

我试图理解Java标准集合库中的API不一致.

I'm trying to understand the API inconsistency in the Java standard collections library.

尽管可以使用size和getIndex()进行模拟，但List或AbstractList中没有方法来获取最后一项.

There is no method in List or in AbstractList to get the last item, although one can simulate that with size and getIndex().

但是，LinkedList支持该功能.

However, LinkedList supports that function.

您知道为什么决定在界面中不支持此方法吗?

Any idea why it was decided not to support this method in the interface?

推荐答案

java.util.List接口不支持getLast()，因为设计人员追求的是最小接口".只需定义最少的方法，它既易于理解，又可以更快地学习.

The java.util.List interface doesn't support getLast() because the designers went for a 'minimal interface'. With the minimal number of methods defined it makes it both easier to understand and quicker to learn.

这与人性化界面"(例如 Ruby数组类)，它尝试提供用于执行常见操作的方法(例如getLast()).由于有很多用途，可以将诸如列表之类的基本概念用于此用途，因此往往会导致更大的界面.

This is in contrast with a 'humane interface' (such as used in the Ruby array class) which attempts to provide methods for doing common operations (e.g. getLast()). As there are many uses which such a fundamental concept as a list can be put to this tends to lead to much larger interfaces.

有关更多信息，请参阅Martin Fowler的最小接口和

For further information see Martin Fowler's Minimal Interface and Humane Interface descriptions.

关于LinkedList为什么支持getLast()等的原因，引用javadoc:

As to why LinkedList supports getLast() etc., to quote the javadoc:

... LinkedList类提供统一命名的方法，以在列表的开头和结尾获取，删除和插入元素.这些操作允许将链接列表用作堆栈，队列或双端队列(双端队列).

... the LinkedList class provides uniformly named methods to get, remove and insert an element at the beginning and end of the list. These operations allow linked lists to be used as a stack, queue, or double-ended queue (deque).

大概认为，对于这些特定用例而言，一般列表并不足够.

Presumably it was felt that a general List would not be adequate for these specific use cases.

为了深入了解Java Collections API的首席设计师(Joshua Bloch)的思想，他提供了他使用的API设计准则列表.其中，与此问题最相关的是:

As an insight into the mind of the principal designer of the Java Collections API (Joshua Bloch) he provides this list of API design maxims by which he works. Of which, the most pertinent to this question are:

API的早期草稿应该简短，通常是一页，其中包含类和方法签名以及一行描述.这样，当您第一次使用不正确时，可以很容易地重新构造API.

Early drafts of APIs should be short, typically one page with class and method signatures and one-line descriptions. This makes it easy to restructure the API when you don't get it right the first time.

如有疑问，请排除在外.如果有API设计的基本定理，就是这样.它同样适用于功能，类，方法和参数. API的每个方面都应尽可能小，但不能更小.您以后总是可以添加内容，但不能删除它们.最小化概念权重比类或方法计数更重要.

When in doubt, leave it out. If there is a fundamental theorem of API design, this is it. It applies equally to functionality, classes, methods, and parameters. Every facet of an API should be as small as possible, but no smaller. You can always add things later, but you can't take them away. Minimizing conceptual weight is more important than class- or method-count.

保留没有实现细节的API.它们使用户感到困惑，并阻碍了发展的灵活性.实施细节并不总是很明显:请警惕超规格.

Keep APIs free of implementations details. They confuse users and inhibit the flexibility to evolve. It isn't always obvious what's an implementation detail: Be wary of overspecification.

最小化可访问性；如有疑问，请将其设为私有.这样可以简化API并减少耦合.

Minimize accessibility; when in doubt, make it private. This simplifies APIs and reduces coupling.

请考虑API设计决策的性能后果，但不要扭曲API以实现性能提升.幸运的是，好的API通常适合快速实现.

Consider the performance consequences of API design decisions, but don't warp an API to achieve performance gains. Luckily, good APIs typically lend themselves to fast implementations.

但是他还说:

不要让客户端做库可以做的任何事情.违反此规则会导致客户端中出现样板代码，这很烦人并且容易出错.

Don't make the client do anything the library could do. Violating this rule leads to boilerplate code in the client, which is annoying and error-prone.

这只是表明设计准则经常会发生冲突，而API设计人员工作中最难的部分就是平衡这些冲突.

Which just shows that design guidelines often conflict and the hardest part of an API designers job is to balance these conflicts.

这篇关于为什么Java List接口不支持getLast()?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！