如何记录覆盖另一个方法的方法？
我一直想知道如何记录重写来自基类的消息的方法。 通常我会向每个公共方法和一些私有、受保护的方法添加一个 java 文档。
但是在 Eclipse 中自动生成覆盖方法的文档块会产生如下内容：
/*
* (non-Javadoc)
*
* @see javax.swing.JComponent#paintComponent(java.awt.Graphics)
*/
这是记录覆盖的好方法吗？ 我应该从基类继承/复制文档吗？
作为这个特殊案例的文档，您正在做什么？ 我想了解一下所使用的做法的概述。
I always wondered how to document a method that overrides a message from a base class.
Normally I add a java doc to each public method and to some private, protected methods.
But autogenerating a documentation block for an override method in eclipse produces something like this:
/*
* (non-Javadoc)
*
* @see javax.swing.JComponent#paintComponent(java.awt.Graphics)
*/
Is this a good way to document the override? Should I inherit/copy the documentation from the base class?
What are you doing as a documentation for this special case?
I would like to have an overview of practices that are used.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
包含 @Override 注释应该足以让好奇的开发人员转向超级。
including the @Override annotation should be enough to send a curious developer to the super.
每个方法——私有的、受保护的公共——都应该记录下来描述它的作用。 忘记从基类继承文档 - 如果您愿意，您可以包含指向它的链接，但只要存在它重写继承方法的信息，那么其他人就可以自由地自行查找它。 DRY - 不要重复自己 - 仅在一处记录基类方法。
我什至不认为最好记录它覆盖的方法，因为这可能会改变，并且如果您在类和基类之间的层次结构中插入新类，则很难保持最新状态。 只需它重写继承方法的信息就足够了。
如果您的方法太复杂而无法用几行注释进行记录，那么它们可能太复杂并且应该重构。
Every method - private, protected public - should be documented describing what it does. Forget about inheriting documentation from a base class - you can include a link to it if you like, but as long as the information is there that it overrides an inherited method then the other person is free to look it up for themselves. DRY - don't repeat yourself - document the base class method in one place only.
I don't even think it is good to document which method it overrides, because that can change and it will be hard to keep it up to date if you insert new classes in the hierarchy between your class and the base class. Simply the information that it overrides an inherited method is sufficient.
If your methods are too complex to document in a few lines of comments, then they are probably too complex and should be refactored.