Question

从弃用的定义：

注释@Deprecated的程序元素是程序员不鼓励使用的程序元素，通常是因为它很危险，或者因为存在更好的替代方案。

另外，据我所知，弃用方法的输出通常与更好的替代的输出相同。

因此，如果方法使用过时的技术并且可能很危险，则应删除它，并且应使用相同的方法定义构建更好的替代。 / p>

因此，根据我这会更好，并且不会激怒那些倾向于使用已弃用的方法的程序员，并列出警告。

有没有理由说明为什么没有这样做，以及为什么用不同的方法签名或完全不同的类别制作新方法？

Answer 1

不能简单地删除或重新实现不推荐使用的方法，因为有时签名和方法的位置与其功能一样错误。

考虑班级

public class Math {
    public static int add(int a, int b) { return a + b; }
    public static int randomNumber() { return 12; }
}

现在有人意识到randomNumber的实现有问题，因为它实际上返回一个常量值。另外，包含upperBound也很不错。它与Math没有任何关系，可能应该转移到类Random而不是：

public class Math {
    public static int add(int a, int b) { return a + b; }

    @Deprecated
    public static int randomNumber() { return 12; }
}

public class Random {
    public static int randomNumber(int upperBound) { return /* some complex implementation */; }
}

在将问题标记为@Deprecated时，您应该始终采取的措施包括您应该使用的替代方法。

在没有给开发人员做出反应的宽限期之前，你不应该删除或改变最初的错误功能，即远离旧方法并使用新方法。因为只是在没有警告的情况下删除或更改它只会破坏每个人的代码，他们可能直到最近才意识到其实际的错误行为。

最后的注释：关于你的陈述

这会更好，并且不会激怒程序员，他们倾向于使用已弃用的方法，并列出警告列表。

从一开始就是一个非常糟糕的习惯。在done的定义中，我写的代码必须是免费警告才能发布。我们根本不允许使用弃用的方法。如果您只是选择忽略警告和已弃用的消息，那么框架的作者就无法做到这一点。不愿意适应的开发人员仍然可以继续，获取已弃用方法的源代码并将其复制到他需要的地方。对于了解框架变化并愿意并且有能力处理它们的开发人员来说，@Deprecated是一个功能。其余的并不重要。 @Deprecated会在某些时候被删除，从而打破那些不愿意改变的人的代码。

关于示例的添加：让我们假设我们有randomNumberBetween0And1错误地实现并始终返回介于1和2之间的值。该函数的用户意识到该错误已更改为使用该方法randomNumberBetween0And1() - 1来弥补错误。如果您现在继续将实现更改为正确的实现，实际返回0到1之间的某些内容将破坏之前通过减1补偿您的错误的每个人的代码 - 这些人现在将获得介于-1和0之间的值回。那是不你想要发生的事情。

Answer 2

不应删除弃用的方法。

如果基本方法被弃用怎么办？您是否要重新编写和重新编译您编写的每个应用程序，因为您想要更新Java版本，或者您希望旧的应用程序仍然有效？

最好不再使用已弃用的方法，这是真的，但为了使Java与以前用Java编写的应用程序兼容，它们应该保留在那里。

因此，根据我的说法，这会好得多，也不会激怒程序员，他们倾向于使用已弃用的方法，使用警告列表。

如果编写合适的代码，则不要使用弃用的方法。一旦方法被弃用，这些警告就可以帮助您改进代码。您应该只收到一次此警告，并相应地调整您的代码。

为什么没有这样做的原因，以及为什么要使用新方法不同的方法定义或完全不同的类？

有时新方法的表现完全相同，有时则不然，并且它获得了额外的功能。如果您只是将旧方法替换为新方法，则可能会更改使用原始方法的所有现有应用程序的行为。

Answer 3

保留已弃用的方法名称的一些原因：

更正拼写/应用命名约定（但修复方法会破坏现有代码）
存在固定方法，但需要更多参数才能正常工作。因此，一个参数调用保持最佳猜测的第二个参数。（java.net.URLDecoder.decode()）
不存在简单修复，但删除会破坏代码

Answer 4

由于各种原因，可以弃用某种方法，这会使您的建议无法实现。大多数情况下，并不是因为这种方法很危险。这是因为有更好的选择。例如：

为弃用的方法选择了错误的名称。它已被一个名字更好的方法所取代：确保保留旧方法是一件好事，因为它并没有打破依赖它的所有现有代码，对吗？
设计已经改变了，并且有一种更好的方法来处理已弃用的方法：再一次，弃用的方法并没有完全被破坏。它可能会在某些极端情况下被破坏，但您不想破坏使用旧方法的所有现有代码，而无需进入这些极端情况。

即使该方法很危险（例如Thread.stop（）），有些人可能知道该方法很危险，意识到这一事实，但他们的代码无论如何都能正常工作并且没有受到影响由于这个问题，重写它会花费太多而没有实际的好处。在没有原始问题的情况下重写相同的方法stop（）根本不可能，因为问题是该方法所做的固有问题：在没有协作的情况下停止线程。

为什么弃用的方法没有重建？

4 个答案: