是否应该在实现中添加Javadoc注释？

在界面中添加Javadoc注释并在实现中添加非Javadoc注释是否正确？

当您自动生成注释时，大多数IDE都会为实现生成非JavaDoc注释。具体方法不应该有描述吗？

对于仅实现（不是覆盖）的方法，请确定为什么不这样做，尤其是如果它们是公共的。

如果您处于压倒一切的情况，并且打算复制任何文本，那么绝对不能。复制是导致差异的必经之路。结果，用户将基于检查父类型还是子类型中的方法而对您的方法有不同的理解。使用@inheritDoc或不提供文档-IDE将在Javadoc视图中使用最少的可用文本。

顺便说一句，如果您的压倒性版本在超类型的文档中添加了内容，那么您可能会遇到麻烦。我在攻读博士学位期间研究了这个问题，发现一般而言，如果人们通过超类型进行调用，他们将永远不会意识到替代版本中的额外信息。

解决此问题是我构建的原型工具的主要功能之一-每当调用某个方法时，您都会得到一个指示，即该方法的目标或任何潜在的超越目标是否包含重要信息（例如，行为冲突）。例如，调用在地图上放置时，会提醒您，如果您的实现是TreeMap，则您的元素需要具有可比性。

实现和接口都应具有javadoc。使用某些工具，您可以使用@inheritDoc关键字继承接口的文档。

/**
 * @inheritDoc
 *
 * This implementation is very slow when b equals 3.
 */
public foo(int b)
{ ... }

采取一些好的做法

/**
 * {@inheritDoc}
 */

作为实现的javadoc（除非对实现的细节有更多的解释）。

通常，当您覆盖方法时，您将遵循在基类/接口中定义的协定，因此您无论如何都不想更改原始javadoc。因此，不需要使用其他答案中提到的@inheritDoc或@see标签，实际上仅在代码中充当噪音。所有明智的工具都从此处指定的超类或接口继承方法javadoc ：

Inherit from classes and interfaces - Inheriting of comments occurs in all
three possible cases of inheritance from classes and interfaces:

- When a method in a class overrides a method in a superclass
- When a method in an interface overrides a method in a superinterface
- When a method in a class implements a method in an interface

在覆盖方法时，默认情况下某些工具（我正在为您看，Eclipse！）会生成这些事实，这只是一种令人沮丧的状态，但是并不能证明您的代码混乱无用。

当您实际上想在覆盖方法中添加注释时（通常是一些其他实现细节或使合同更加严格），当然可能存在相反的情况。但是在这种情况下，您几乎永远不想做这样的事情：

/**
 * {@inheritDoc}
 *
 * This implementation is very, very slow when b equals 3.
 */

为什么？因为继承的注释可能很长。在这种情况下，谁会注意到3个长段落末尾的多余句子？相反，只需写下您自己的评论即可，仅此而已。所有的javadoc工具总是显示某种指定者”链接，您可以单击该链接以阅读基类注释。混合它们是没有意义的。

@see它会生成一个指向界面描述的链接。但我认为也可以添加有关实现的详细信息。

Sjoerd正确地说，接口和实现都应具有JavaDoc。接口JavaDoc应该定义方法的约定-方法应该做什么，需要什么输入，应该返回什么值以及在发生错误的情况下应该做什么。

实施文档应记录合同的扩展或限制，以及实施的适当细节，尤其是性能。

为了生成javadoc，它确实很重要。如果仅使用接口声明对具体实现的引用，则不会声明，因为IDE将检索接口的方法。