Javadoc评论是否应该添加到实现？
在界面中添加Javadoc注释并在实现中添加非Javadoc注释是否正确？
自动生成注释时，大多数IDE都会为实现生成非JavaDoc注释。 具体的方法不应该有描述吗？
对于只是实现（而不是覆盖）的方法，当然，为什么不呢，特别是如果它们是公开的。
如果你有一个压倒一切的情况，你会复制任何文本，那么肯定不是。 复制是导致差异的绝对方法。 因此，根据用户是否检查超types或子types的方法，用户会对您的方法有不同的理解。 使用@inheritDoc或不提供文档 – IDE将在其Javadoc视图中使用最低的可用文本。
顺便说一句，如果您的重写版本添加了超types的文档的东西，你可能会陷入一个麻烦的世界。 我在博士学习期间研究了这个问题，发现一般情况下，如果通过超types调用，那么人们将永远不会意识到压倒一切的版本中的额外信息。
解决这个问题是我构build的原型工具的一个主要特征 – 每当你调用某个方法时，就会得到一个指示，表明它的目标或任何潜在的重要目标是否包含重要的信息（例如，相冲突的行为）。 例如，当调用放置在地图上时，提醒您如果您的实现是TreeMap，则您的元素需要具有可比性。
实现和接口都应该有javadoc。 使用一些工具，您可以使用@inheritDoc关键字inheritance接口的文档。
/** * @inheritDoc * * This implementation is very slow when b equals 3. */ public foo(int b) { ... }
比较好的做法是放
/** * {@inheritDoc} */
作为实现的javadoc（除非需要额外解释实现的细节）。
@see它会在界面中生成一个指向描述的链接。 但是我觉得也可以添加一些关于实现的细节。
Sjoerd正确地说，接口和实现都应该有JavaDoc。 接口JavaDoc应该定义方法的约定 – 方法应该做什么，它需要什么input，应该返回什么值，以及在错误的情况下应该做什么。
实施文档应该注意合同的扩展或限制，以及实施的适当细节，尤其是性能。
一般来说，当你重写一个方法时，你坚持在基类/接口中定义的契约，所以你不想改变原来的javadoc。 因此，在其他答案中提到的@inheritDoc或@see标签的使用是不需要的，实际上只是代码中的噪声。 所有合理的工具从超类或接口inheritance方法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. */
为什么？ 因为inheritance的评论可能会很长。 在这种情况下，谁会在3个长段结尾处注意到额外的句子？ 相反，只要写下你自己的评论，这就是全部。 所有的javadoc工具总是显示某种指定的链接，您可以点击阅读基类评论。 混合它们没有意义。
为了生成javadoc是的，它确实很重要。 如果仅使用接口声明具体实现的引用，则不会由于接口的方法将被IDE检索。
