Collection<E>&Queue<E>&BlockingQueue<E>接口中的add( e )方法

Question

问题1：

在读取JDK源代码时，我发现接口Collection<E>&Queue<E>&BlockingQueue<E>中定义了boolean add(E e);方法。

我无法理解这一点。根据我的理解，如果一个超级接口已经定义了一个方法，那么扩展这个超级接口的子接口就不必再定义这个方法了。

那么，为什么这个方法被定义了三次呢？

问题2：

我还注意到，与boolean add(E e);方法不同，后者在接口Queue<E>中声明，然后在接口BlockingQueue<E>中重新声明，E poll();方法仅在接口Queue<E>中声明，而在接口BlockingQueue<E>中没有被重新声明。

那么，他们为什么受到不同的对待呢？

Answer 1

问题1:在读取JDK源代码时，我发现了布尔型add( e )；定义在接口Collection&Queue&BlockingQueue中。 我无法理解这一点。根据我的理解，如果一个超级接口已经定义了一个方法，那么扩展这个超级接口的子接口就不必再定义这个方法了。

是的你不需要重新定义它。我猜这很可能是因为您需要重复声明才能添加新的JavaDoc注释，也就是说，每个接口都对add(E)等的功能有一个特定的描述。

问题2:我还注意到，与在接口队列中声明，然后在接口BlockingQueue中重新声明的布尔add( e )；方法不同，E轮询()方法只在接口队列中声明，而在接口BlockingQueue中没有被重新声明。 那么，为什么对待他们的方式不同呢？

可能和上面一样。poll(E)对一般队列和阻塞队列的工作方式相同，因此不需要不同的文档。

Answer 2

这里的区别只是在文档上。-- E poll()方法签名--在BlockingQueue中没有提到，因为Queue和BlockingQueue的契约是相同的，而两者的文档解释了两个数据结构的行为是相同的。

如果您查看Queue.add()和BlockingQueue.add()的文档，您将看到在BlockingQueue.add()方法上添加了一个额外的句子。

Queue.add()

如果可以在不违反容量限制的情况下立即将指定的元素插入到此队列中，则在成功时返回true，如果当前没有可用的空间，则会抛出IllegalStateException。

BlockingQueue.add()

如果可以在不违反容量限制的情况下立即将指定的元素插入到此队列中，则在成功时返回true，如果当前没有可用的空间，则会抛出IllegalStateException。当使用容量受限的队列时，通常最好使用offer。

这是为了帮助开发人员在使用相关对象时。

从技术上讲，add()方法是相同的，因此BlockingQueue不需要显式指定该方法签名。

Answer 3

我相信这更多的是与定义行为的行为有关。从技术上讲，不需要在队列或阻塞队列中定义add，但是由于add的行为可能有所不同，这取决于Collection是一个集合还是一个队列，因此最好重新定义它，以便人们能够确切地了解队列添加方法所期望的内容。

因此，只要行为不应该改变或增强，就没有必要在子接口中声明该方法，但是如果您期望行为是特定的，那么就应该继续并重新声明它。