Java 的集合接口和类层次结构做得不好吗？

Question

我知道在 Java 中，LinkedList class implements both Deque and List 接口。 这让我有些困惑。

在计算机科学教学大纲中，我从未被告知队列可以是一个列表，或者更准确地说，队列可以表现得像一个列表。也就是说，列表可以做一些事情，但队列不能。但是该列表可以表现得像一个队列。比如List接口有the following methods：

add(E e)
add(int index, E element)

但是Queuehas only the following:

add(E e)

很明显Queue 不允许在特定索引处插入，而List 允许插入。与Queue.remove() 与List.remove(int index)、List.get(int index) 与Queue.peek() 等其他操作的情况相同。 也就是说，list 是一种更通用的数据结构，可以模拟Queue。

现在能够模拟与拥有合同子集不同。也就是说，Queue 不允许 List 的某些操作（索引）并且只允许以特定方式完成某些操作（仅在尾部插入并仅从头部移除）。所以Queue 并没有真正“添加”到List 的合同。这正是为什么Queue 没有在Java 集合框架中扩展List，而是都扩展Collection 接口的原因。我相信这也是为什么任何类都实现两者都不正确的原因，因为Queue 的合同与List 的合同冲突（这就是为什么他们分别从Collection 接口分叉出来的原因）。但是，LinkedList 实现了这两个接口。

我也遇到过this 回答：

LinkedList 实现恰好满足Deque 契约，那么为什么不让它实现接口呢？

我仍然不明白我们怎么说“LinkedList 实现恰好满足Deque 合同”。队列的概念不允许在任意索引处插入。因此，Queue 接口没有这样的方法。

但是，我们只能通过接口强制执行合同，不能禁止某些方法的实现。作为列表（名称中有“List”），我觉得在LinkedList 中有队列方法peek()、pop() 和add(int index, E element) 是不正确的。

我相信，相反我们应该有单独的类LinkedQueue，它可以有队列的链接实现，类似于LinkedBlockingQueue，它包含BlockingQueue 的链接实现。

还要注意LinkedList 是唯一继承自列表和队列家族的类，也就是说，没有其他类同时实现List 和Queue (AFAIK)。这是否表明LinkedList 做得不好？

我是不是完全错了，而且是在不必要地思考？

Answer 1

你完全忽略了programming to interface 的意义。

如果你需要Queue，你永远不要写：

LinkedList<String> queue = new LinkedList<>();

因为，您是对的，这将允许您使用非队列方法。相反，您可以像这样对界面进行编程：

Queue<String> queue = new LinkedList<>();

现在您只能访问 6 个Queue 方法（以及所有Collection 方法）。因此，即使LinkedList 实现了更多方法，您也无法再访问它们。

因此，如果您需要队列，请选择最适合您所需的性能、存储和访问特性的Queue 接口的实现，例如

• LinkedList 使用更多内存，但在队列清空时会缩小。

• ArrayDeque 使用较少的内存，但不会缩小。

• PriorityQueue 是一个具有元素优先级的非 FIFO 队列。

• ConcurrentLinkedQueue、ConcurrentLinkedDeque支持多线程并发访问。

• 还有更多...

---

我从来没有被告知队列可以是一个列表，或者更准确地说，队列可以表现得像一个列表。

请记住，implements 定义了 behaves like 关系。 LinkedList 表现得像 List。 LinkedList 表现得像 Deque。 LinkedList 表现得像 Queue。

但仅仅因为 LinkedList 的行为与所有这些相似，并不意味着 List 表现得像 Queue 或 Queue 表现得像 List。他们没有。

behaves like 关系只有一种方式。

Answer 2

@Andreas 的回答非常好，所以我的目标是你关于你被教导或未被教导的论点：

在计算机科学课程中，我从来没有被告知队列可以是一个列表，或者更准确地说，队列可以像一个列表一样工作

队列不仅仅是任何列表，而是一种特殊的列表，具有自己的特殊属性和约束。

也就是说，列表可以做一些事情，但队列不能。

不，List 无能为力。它提供了由一个类实现的可能性，并且如果该类决定实现它们，那么该类可以做所有这些事情。

但列表可以像队列一样工作。

不，List 不正常；它只建议实现它的行为和类可以接受它们的全部或一部分，或者它们可以定义新的。

Answer 3

LinkedList 是一个实现List 和Deque 接口的类。这些接口中的每一个都定义了一个带有操作的契约，并且在这些契约中指定了这些操作必须执行的什么。但是，没有具体说明如何这些操作应该工作。

LinkedList 是一个实现List 和Deque 接口的类。因此，尽管后缀 List 是 LinkedList 类名称的一部分，LinkedList 实际上既是 List 又是 Deque，因为它实现了在 @987654333 中定义的所有操作@ 和 Deque 接口。

所以LinkedList是一个List，它也是一个Deque。这并不意味着List 应该是Deque，或者Deque 应该是List。

例如看下面的接口：

public interface BloodDrinker {

    void drinkBlood();
}

public interface FlyingInsect {

    void flyAround();
}

上面的每个接口都有一个操作并定义了一个合约。 drinkBlood 操作定义了 BloodDrinker 必须做什么，而不是如何做。同样适用于FlyingInsect：它的flyAround 操作定义了它必须做什么，而不是如何做。

现在考虑Mosquito 类：

public class Mosquito implements FlyingInsect, BloodDrinker {

    public void flyAround() {
        // fly by moving wings, 
        // buzzing and bothering everyone around
    }

    public void drinkBlood() {
        // drink blood by biting other animals:
        // suck their blood and inject saliva
    }
}

现在，这意味着Mosquito 既是FlyingInsect 又是BloodDrinker，但是为什么吸血者一定是飞虫，或者飞虫一定是吸血者？例如，吸血鬼是吸血者，但不是飞虫，而蝴蝶是飞虫，但不是吸血者。

---

现在，关于您关于 Queue 不允许某些 List 的操作（索引），并且只允许以 FIFO 方式在其末端添加/删除的论点......我不认为这个理由是正确，至少在 Java 集合框架的上下文中。 The contract of Deque 没有明确提到实现者永远无法在任何给定索引处添加/删除/检查元素。它只是说Deque 是：

支持两端元素插入和删除的线性集合。

它还说：

此接口定义方法以访问双端队列两端的元素。

（强调我的）。

几段之后，它确实明确表示：

与List 接口不同，此接口不支持对元素的索引访问。

（再次强调我的）。

这里的关键部分是不提供支持。它从不禁止实现者通过索引访问元素。只是不支持通过Deque 接口进行索引访问。

想想我上面的例子：为什么BloodDrinker 不允许它的实现者喝血以外的东西，即水？或者为什么 FlyingInsect 不允许其实现者以不同于飞行的方式移动，即步行？

最重要的是，只要这些合同不相互矛盾，实施就可以根据需要遵守任意数量的合同。正如它在 Java 中的措辞（一个非常谨慎和微妙的措辞，我必须承认），Deque 的合同与 List 的合同并不矛盾，因此可以完美地存在一个实现这两个接口的类，并且这个恰好是LinkedList。

Answer 4

你是从一个弱前提开始的：

我从来没有被告知队列可以是一个列表。

让我们回到基础。那么什么是数据结构呢？以下是CLSR 处理该问题的方式¹：

...虽然数学集合是不变的，但由 算法可以随时间增长、缩小或以其他方式变化。

在数学上，数据结构只是集合；动态集。从这个意义上说，队列可以是一个列表。其实CLSR（10.2-3）有一个问题，就是明确要求你用链表来实现队列。

另一方面，面向对象编程是一种范式，它通过坚持关于问题和数据的特定哲学来帮助程序员解决问题。对象、接口和契约都是这一理念的一部分。使用这种范式可以帮助我们实现动态集合的抽象概念。然而，它有自己的行李，其中之一就是这里要问的问题。

因此，如果您抱怨 Java 标准库中的数据结构没有严格遵守为基本数据结构定义的约定，那么您是对的。事实上，我们甚至不需要看java.util.Stack 就可以看到这个²。您还可以以任何您想要的方式推出自己的实现并使用它们而不是标准库集合。

但要争辩说 Java 或其标准库已损坏或做得不好 - 一个非凡的主张 - 你需要非常具体地了解用例并清楚地展示如何库中的所谓缺陷会阻止您实现设计目标。

---

^{1_{第三章介绍，p220}}

^{2_{Sedgewick and Wayne 调用 java.util.Stack 一个“宽接口”（p 160），因为它允许随机访问堆栈元素；堆栈（在基本数据结构中定义）不应该具备的能力。}}

Answer 5

您在这方面是完全正确的，完全没有错过重点。 Java 只是在正确性和易用性之间进行了权衡。让它同时实现这两个接口是简单的事情，也是对开发人员最有用的的事情。

什么是子类型

正确的（声音）子类型需要substitution 才能工作，这需要根据 LSP：

超类型的不变量必须保存在子类型中。

当我们在类型理论中说“LinkedList 是一个列表和一个队列”时，我们实际上是在说一个 LinkedList既是一个列表又是一个队列同时 并且不是 LinkedList 可以被认为是一个列表或一个队列。

这里有一个队列类型的violated invariant（你不能修改它中间的元素），所以它是不正确的子类型。

应该有的实际参数是“队列是否要求元素不能在中间修改或仅在FIFO中可以在末端修改”。

有人可能会争辩说，队列的不变量只是您可以在 FIFO 问题中使用它，而不是您必须。这不是队列的常见交互方式。