当我们有 peek() 和 poll() 时，在 Queue 接口中有 element() 和 remove() 有什么用？
我检查了文档，发现这些方法也存在于 java 7 中。提到的唯一区别是 element() 和 remove() 为空队列抛出异常。如果队列为空，我们可以手动抛出异常（如果需要）。
是否真的有必要为这唯一的区别保留两组方法？如果我们开始根据这些差异制作不同的方法，我认为 java 类和接口将充满很多方法。这是真正的面向对象风格吗？
编辑：只是为了让我的问题清楚，所以我没有得到相同的“你需要例外的地方使用这个，否则使用那个”的答案。我无法理解的是有很多这样的方法，其中具有相同差异的额外方法将很有用。那么为什么它只在某些情况下实施而不在其他情况下实施呢？为什么没有整体应用相同的原则？我可以理解，也许只有语言创造者才能回答这些为什么。我想知道这种方法是否符合 OOP 原则？
有必要吗？......可能。也许，也许不是。
通常，您应该更喜欢element()或者remove()如果队列在程序中的这一点永远不应该为空。这是快速失败的一般原则的一部分：如果出现问题，请尽快抛出错误，以便对其进行调试。（如果您的程序没有在错误发生时立即抛出，那么跟踪该错误将变得非常困难，因为您稍后只能在堆栈中的不同位置发现它。）
也就是说，当您不知道队列是否为空并且想要找出时，异常可能具有不可接受的开销，返回 null 可能更可取。
这显然是一个判断电话，我可以想象可能会做出不同的决定，但我认为做出的决定至少是合理的。在某些情况下有充分的理由偏爱element()，而在其他情况下有充分的理由偏爱。peek()peek()element()
就“为什么在某些情况下使用这种方法而不在其他情况下使用这种方法”而言……答案各不相同，而且始终是一个高度主观的判断要求。在许多情况下，当 null 永远不会是“肯定”答案时，JDK 经常在“失败”时返回 null，否则会抛出异常——例如，NavigableMap.firstKey()可以返回 null，因为 null 是第一个键，所以它会NoSuchElementException在空时抛出 a map, whileNavigableMap.firstEntry()在空地图上返回 null 因为不可能null与有效返回混淆。
例外是差异。如果您的 Queue应该有元素，请使用element()or remove()，因此如果 Queue 为空，则会出现异常。如果 Queue 可以为空是合理的，则使用 poll() 和 peek() 并处理该null值。
至于这种方法是否符合 OOP 原则——我认为这无关紧要。OOP 的三大支柱（多态性、继承性和封装性）不包括包含可疑必要性的方法。OOP 不是解决效率和有效性问题。
包含抛出异常的方法有一个半正当的理由：它们的存在允许解决方案，其中 anull是队列中的合法项目。每当您需要这样的场景时，如果没有这些方法，您就需要创建一个表示 null 的“null-sentinel”值；使用这些方法可以减少样板文件。