为什么 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.

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

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 类提供统一命名的方法来获取、删除和插入列表开头和结尾的元素.这些操作允许链表用作堆栈、队列或双端队列(deque).

... 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屋！