【问题标题】:Why element() and remove() when we have peek() and poll() in java [closed]当我们在 java 中有 peek() 和 poll() 时为什么要 element() 和 remove() [关闭]
【发布时间】:2012-11-06 17:22:40
【问题描述】:

当我们有 peek() 和 poll() 时,在 Queue 接口中有 element() 和 remove() 有什么用?

我检查了文档,发现这些方法也存在于 java 7 中。 提到的唯一区别是 element() 和 remove() 为空队列抛出异常。 如果队列为空,我们可以手动抛出异常(如果需要)。

真的有必要为这唯一的区别保留两组方法吗?如果我们开始根据这些差异制作不同的方法,我认为 java 类和接口将充满很多方法。这是真正的面向对象风格吗?

编辑:只是为了让我的问题清楚,所以我没有得到相同的“你需要例外的地方使用这个,否则使用那个”的答案。 我无法理解的是有很多这样的方法,其中具有相同差异的额外方法将很有用。那么为什么它只在某些情况下实施而不在其他情况下实施呢?为什么没有整体应用相同的原则?我可以理解,也许只有语言创造者才能回答这些为什么。 我想知道这种方法是否符合 OOP 原则?

【问题讨论】:

  • Java 在这方面相当保守。例如,请参阅 ruby​​ 中的方法范围或 Array 和类似的类。
  • 它们当然存在于 Java 7 中。您不能只从产品中删除功能。

标签: java data-structures queue


【解决方案1】:

有必要吗? ......可能。也许,也许不是。

一般来说,如果队列在程序中的这一点永远不应该是空的,那么您应该更喜欢element()remove()。这是快速失败的一般原则的一部分:如果出现问题,请尽快抛出错误,以便对其进行调试。 (如果您的程序没有在错误发生时立即抛出,那么跟踪该错误将变得非常困难,因为您稍后只能在堆栈中的不同位置发现它。 )

也就是说,如果您不知道队列是否为空,并且您想知道,那么异常可能具有不可接受的开销,返回 null 可能更可取。

这显然是一个判断电话,我可以想象可能会做出不同的决定,但我认为做出的决定至少是合理的。在某些情况下,选择element() 而不是peek()的理由,而在其他情况下,有充分的理由选择peek() 而不是element()

就“为什么在某些情况下使用这种方法而不在其他情况下使用这种方法”...答案各不相同,而且它始终是一个高度主观的判断要求。在许多情况下,当 null 永远不会是“肯定”答案时,JDK 经常在“失败”时返回 null,否则抛出异常——例如,NavigableMap.firstKey() 可以返回 null,因为 null 是第一个键,所以它抛出一个NoSuchElementException 在空映射上,而 NavigableMap.firstEntry() 在空映射上返回 null,因为不可能将 null 与有效返回混淆。

【讨论】:

  • 谢谢。我已经编辑了这个问题,以便我要问的更清楚:)
【解决方案2】:

区别就是例外。如果您的队列应该有元素,请使用element()remove(),因此如果队列为空,则会出现异常。如果 Queue 可以为空是合理的,则使用 poll() 和 peek() 并处理 null 值。

至于这种方法是否符合 OOP 原则 - 我认为这无关紧要。 OOP 的三大支柱(多态性、继承性和封装性)不包括包含可疑必要性的方法。 OOP 不是为了解决效率和有效性问题。

【讨论】:

  • OP 清楚地知道其中的区别。 OP 的问题是为什么一开始就值得拥有差异如此之小的方法。
  • 让我印象深刻的是 null 和异常之间存在显着差异
  • 明显不同...当然。但是我也可以看到 OP 的观点,提供peekpoll 可能就足够了,根本没有抛出异常的方法,那么为什么要添加这些额外的方法呢?这是一个有效的问题,但这个答案并没有真正回答。
  • @LouisWasserman 我不同意。这是唯一可能没有读懂设计师想法的答案。其中大部分也包含在您的答案中。
  • 我将 OP 的问题解读为“我无法想象设计师有任何理由这样做;人们可以给出理由吗?” “这些是方法之间的差异”不是原因。
【解决方案3】:

包含抛出异常的方法有一个半正当的理由:它们的存在允许一个解决方案,其中null 是队列中的合法项目。每当您需要这样的场景时,如果没有这些方法,您就需要创建一个表示 null 的“null-sentinel”值;使用这些方法,样板文件更少。

【讨论】:

    猜你喜欢
    • 2013-08-03
    • 2021-11-05
    • 1970-01-01
    • 2015-07-25
    • 1970-01-01
    • 2023-03-15
    • 2015-09-07
    • 2014-07-04
    • 1970-01-01
    相关资源
    最近更新 更多