首页 > 解决方案 > 如何在java中将方法标记为不鼓励?

问题描述

我正在编写一个读取文件并将配置参数作为映射提供的配置类。参数可以通过conf.get("LogLevel")或访问conf.getLogLevel()

第一个函数只是从映射中读取并返回值(可以是null或无效的),而第二个函数将值转换为 LogLevel 并在没有给出有效值时返回默认值。

因此我想劝阻程序员不要使用 general get(),但在特殊情况下这种方法很有用,所以我不能让它受到保护。现在我使用@Deprecated,但我认为这不是一个好的解决方案,因为它只是用于将来将被删除的方法。(如果我错了,请纠正我,这就是 SonarLint 告诉我的关于 @Deprecated 注释的内容)

/**
 * @Deprecated When possible, use the key-specific getter instead
 */
public String get(String key) {
    return values.get(key);
}

public int getLogLevel() {
    return Log.getLogLevel(values.get(LOG_LEVEL), Log.getLogLevel(defaultValues.get(LOG_LEVEL)));
}

标签: javajavadoc

解决方案


好吧,如果@Deprecated不是解决方案,那么您只剩下一个选择。将说明用法“不鼓励”(特殊情况除外)的消息放入 javadocs ...并希望人们阅读 javadocs。

定义您自己的自定义注释将无济于事,因为您无法让您的用户使用能够识别它的注释处理器。

同样,您不能通过针对 FindBugs、PMD、Sonar 等的自定义规则来做到这一点,因为这需要您的用户自定义他们对这些产品的安装。

(虽然......如果这是一个内部产品并且您的所有用户都使用公共 CI 服务器......您可能会在 CI 服务器中进行检查。这取决于您是否可以定义可以可靠地区分的自定义规则特殊情况中的一般“不鼓励”用例。这也需要说服你的同事这是一个好主意。)


在我看来,这个@Deprecated标签会比上面所有的都好。对于特殊情况,鼓励人们明智地添加@SuppressWarning("deprecation")需要使用的情况。

我认为这不是一个好的解决方案,因为它仅适用于将来将被删除的方法。

这是不正确的。未来可能的删除只是javadoc(Java 11 版本)中列出的弃用的示例原因之一。列出的其他原因有:@Deprecated

  • "标记元素的使用很可能导致错误",
  • “它可能会在未来的版本中以不兼容的方式更改 [...]”,
  • “它已被更新的、通常更可取的替代品所取代”,或
  • “它已经过时了”。

请注意,这些被列为示例原因......这意味着您可以出于其他原因弃用。

这也与此处较早的“何时弃用”指南一致。

IMO,您的“气馁”情况已涵盖其中。


推荐阅读