Is there any other reason why NULL is not allowed in ArrayDeque besides "null is used as a special return value"?

huangapple go评论68阅读模式
英文:

Is there any other reason why NULL is not allowed in ArrayDeque besides "null is used as a special return value"?

问题

在您尝试查找重复的问题或负投票之前,请允许我解释一下 Is there any other reason why NULL is not allowed in ArrayDeque besides "null is used as a special return value"?

我认为我阅读了大多数关于这个主题的stackoverflow答案。它们都总结到了这一点:

> 不应将null插入队列,因为null也被某些方法用作特殊的返回值,表示队列不包含任何元素。

他们完全正确(在这里我们忽略LinkedList)。例如,如果我调用queue.poll()queue.peek(),并且返回类型是null,我就不会知道那个null是作为元素表示的null还是作为null表示没有元素

但是,任何具有基本知识的程序员都可以像这样做来避免出现问题:

            //队列初始化..            
            queue.add(null);
            if (!queue.isEmpty()){
                System.out.println(queue.poll());
            }

所以我必须再次问。是不是“作为特殊返回类型的null”只是它在大多数Queue实现(除了LinkedList)中被“禁止”的唯一原因?还是我在这种情况下漏掉了其他什么东西?

英文:

Before you try to find duplicate question or downvotes, please let me explain Is there any other reason why NULL is not allowed in ArrayDeque besides "null is used as a special return value"?

I think I read most of stackoverflow answers on this topic. They all summarize to this:

> Null should not be inserted into a Queue, as null is also used as a
> special return value by some methods to indicate that the queue
> contains no elements.

They are totally right (let's ignore LinkedList here). If I were to call for example queue.poll() or queue.peek() and return type is null, I wouldn't know if that null represents null as element or null as no elements.

But any programmer with basic knowledge can do something like this to avoid given problem:

            //queue initialization..            
            queue.add(null);
            if (!queue.isEmpty()){
                System.out.println(queue.poll());
            }

So I must ask again. Was "null as special return type" only reason why it is 'banned' in mostly Queue implementations(except LinkedList)? Or I am missing something additional concerning this situation?

答案1

得分: 2

队列的实现本可以被设计成允许空条目,但事实并非如此。这是一个设计权衡:能够插入空条目的“灵活性”与在调用部分旨在确定队列是否包含任何元素的方法之前必须检查队列是否包含任何元素的繁琐编程界面之间的权衡。

线索在于名字中的“poll”。如果poll无法执行“移除并返回;否则指示没有要返回的内容”的操作,那么poll就不是一个有用的方法;对空进行测试,然后进行现有的“remove”调用,就可以完成工作。

因此,我认为队列设计者可能考虑了一个包含“事物”而不是事物缺失的队列(即,他们字面上采用了这个词),并为了单一方法poll的便利性而接受了这个限制。

简而言之,我的回答是“是,这就是原因”,但我认为这个原因是一个很好的原因。

英文:

The queue implementations could have been designed to permit null entries, but they were not. This is a design tradeoff: the 'flexibility' of being able to insert null entries, versus the cumbersome programming interface of having to check whether the queue contains any elements before you can call a method that is there in part to determine whether the queue contains any elements.

The clue is in the name 'poll'. If poll is not able to perform a 'remove and return; else indicate nothing to return', then poll is not a useful method; a test for empty, followed by the existing 'remove' call, does the job.

I suppose, therefore, that the queue designers had in mind a queue that contained 'things' rather than the absence of things (i.e., they took the word literally) and accepted that restriction for the convenience of a single-method poll call.

In short, your answer (IMO) is 'yes, that is the reason', but I think the reason is a good one.

huangapple
  • 本文由 发表于 2020年10月4日 08:59:52
  • 转载请务必保留本文链接:https://go.coder-hub.com/64190266.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定