【发布时间】:2022-08-22 00:34:25
【问题描述】:
我喜欢使用 Builder 模式来实例化具有复杂状态的类的对象,而不是使用太多的构造函数参数。
我可以将 JavaDoc 添加到类和每个单独的方法中,但我所知道的 JavaDoc 关键字似乎都不适合记录构建器的特殊性,例如哪些设置是强制性的,可选设置的默认值是什么。
如果我为每个单独的方法记录强制或可选和默认值,感觉就像文档传播得太多而无法全面了解它。如果我只记录最终的 build() 方法,告诉它何时可以使用默认值构建实例,以及何时不能。
这些选项似乎都不是真正令人满意的。感觉 JavaDoc 不太适合构建器模式,而是为遗留的面向对象代码风格设计的;这个或者我理解的不够好。
我搜索了https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html 文档,但找不到使用正确标签记录生成器的答案或指南。
@param 看起来像是一个有效的候选人,可以在 Builder 类本身这样的地方记录来自构建器的所有 setFoo、withBar、addBaz,但它似乎不适合这种用法。
如何在 JavaDoc 或其他更合适的工具中正确记录 Builder?
-
用一块石头解决 2 个问题: 问题 1:一般来说,现在 cmets 形式的文档是一种反模式——你应该把事情命名得足够好,以至于它们不需要文档。罕见的例外是方法契约的特殊细微差别。问题2:不要写任何代码!解决方案:将 Lombok 的
@Builder注释添加到您的类中,您就完成了! -
没有用于记录构建器的任何特定 Javadoc 标记,至少默认 doclet 没有提供。您可以定义自己的标签,但这可能比它的价值更多。我会查看其他构建器是如何记录的(在 JDK 和第三方库中),然后使用您最喜欢的方法。
-
@Bohemian我恭敬但强烈不同意。方法名称不能告诉其他开发人员对参数和返回类型的约束。方法名称无法解释引发特定异常的原因。方法名称不能扩展行业特定术语的含义。在我看来,龙目岛是有毒垃圾;它在许多方面与面向对象开发相反,我无法一一列举。
-
@slaw 如果方法名称足以暗示其合同,请不要添加 cmets/doc。例如
Optional<Post> getMostRecentPost(int userId) throws NoSuchUserException不需要任何文档或解释。如果一段代码需要 cmets,那么将代码块分解成自己的方法并用简洁版本的 cmets 命名是一个很大的危险信号。顺便说一句,如果某些 cmets 由于无法通过更好的命名来解决的特殊性而并非绝对需要,我会拒绝 PR。加上我的团队已经很多年没有部署任何错误,所以该模式有效。 -
@slaw 这只是一个例子。至少该方法应该需要最少的 cmets - 也就是说,什么能够好的命名应该是暗示的(像
findFirstPostExceptThoseMadeOnNewYearsEve()这样的方法名称显然很荒谬)。无论剩下什么不能简单地通过良好的命名来暗示,都值得评论。见POLA。