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