为什么 Deque delcare 方法与它扩展的 Queue 接口具有完全相同的功能？答案

【问题标题】：Why Deque delcare on method with exactly the same functionality as the Queue interface which it extends?为什么 Deque delcare 方法与它扩展的 Queue 接口具有完全相同的功能？
【发布时间】：2020-02-13 13:45:48
【问题描述】：

我不明白为什么虽然 Deque 接口扩展了队列接口，但 Deque 接口重复了 Queue 方法。例如： 1. 为什么 Queue 接口在 getFirst 方法上声明，而不是“满足”与“元素”做同样的事情（并且继承自 Queue 接口）。如果我们看一下 LinkedList 类（它实现了 Deque 接口），元素方法的实现除了调用“getFirst”方法之外什么也没做。为什么 Deque 在 getFirst 方法上声明？ 2.method peek（继承自 Queue 接口）与 peekFirst 方法具有完全相同的实现（似乎是复制粘贴）？为什么 Deque 声明 peek 方法？我可以找到另一个例子，但我认为我的情况很清楚，但我认为这就足够了

【问题讨论】：

标签： java collections interface queue deque

【解决方案1】：

Deque 与Queue 执行相同的操作，并且还有其他方法可以从另一端访问Deque 的元素。因此Double Ended Queue。因此，Deque 接口只是简单地扩展了 Queue 接口，并利用这些方法方便地将其用作队列。

因此，如果您有一个 Deque 并尝试执行 add()，它会像 addFirst() 一样工作。但是Queue 不支持addFirst()。所以，imo，这是为了方便。 API 还告诉您哪些方法是等效的。他们只是不告诉你为什么。

查看此内容以获取更多信息。 Double Ended Queue

【讨论】：

对不起，我很欣赏你的回答，但我会加倍深入。我没有找到任何合理的解释，为什么 Deque 不能对 Queue 方法“满意”，并且它声明了其他方法，这些方法被定义为执行与它继承的功能相同的功能。也许与“遗留”问题有关的原因。我真的很想知道谁是给我负 1 的“天才”。在我发布我的问题之前，我阅读了 Java API 中的所有信息，并在 Stackoverflow 上寻找类似的问题。
我不认为这是遗产。这可能只是为了方便或保持一致。对于Deque，拥有addLast 是有意义的。所以有人可能会期待addFirst。