【问题标题】:Removing deprecated functionality from a library从库中删除不推荐使用的功能
【发布时间】:2011-01-10 16:06:40
【问题描述】:

假设我的 api 中有一个名为 foo 的方法。在我的 api 的下一个版本中,我想用bar 替换这个方法。我该怎么做呢?

有几个选项:

1) 只需删除foo。在发行说明中,声明此方法已被bar 取代。当客户尝试使用我的新库进行构建时,这会破坏客户,但谁在乎呢?他们只需要自己解决问题。

2) 将foo 标记为已弃用,并在发行说明中声明应首选bar。调用不推荐使用的方法时记录警告。然后在下一个版本中,完全删除foo。这为客户提供了一个小的警告窗口。

你会怎么做?

【问题讨论】:

标签: java api language-agnostic deprecated


【解决方案1】:

一定要做2。

上面的 1 不仅会影响编译时,而且如果您的库 jar 被最终用户替换,也会导致运行时错误。

【讨论】:

  • 而且,根据您的部署基础的广度,您可能需要的不仅仅是“小警告窗口”,因此您可能希望在之前经历多个版本(越来越刺耳的警告 :-)完全删除旧功能。
  • @David:例如,Java 的标准库从未删除任何内容,即使是标记为已弃用的部分。
【解决方案2】:

执行 2,然后执行 1。

在您的“小警告窗口”期间,让您的客户清楚 bar 风靡一时,并确保所有(或根据您的判断,大多数)不再依赖于 foo,然后再移除死者从你的图书馆重量。这样,您的客户可以在自己方便的时候解决问题,而不是被二进制中断所强迫。

当然,正如大卫所说,您需要根据您的用户群规模做出自己的判断。如果这是一个仅由几个密切接触者使用的小型库,那么仅进行更改可能会更有效,但将其标记为已弃用是好形式

【讨论】:

    【解决方案3】:

    您的秒选择是处理方法替换的标准。

    【讨论】:

      【解决方案4】:

      如果客户端程序在我的控制之下,并且我对它们有良好的测试覆盖率,那么我将客户端切换到新签名并删除旧签名。否则我会弃用旧签名。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2014-01-16
        • 2014-05-10
        • 1970-01-01
        • 1970-01-01
        • 2016-05-21
        相关资源
        最近更新 更多