什么时候不推荐使用Java

作为重构工作或正在进行的开发的一部分，某种方法或整个类可能会在某种意义上过时。Java支持该@Deprecated注释，以指示可能存在更好的方式来处理所涉及的功能。我想这在公共API中特别有用，在公共API中可能不知道删除API部分的影响。对于非公共API和使用版本控制系统的项目（从某种意义上讲，可以撤消删除操作），什么时候宜弃用而不是删除过时的元素？

您的API是面向公众的API吗？这决定了您是否应该弃用或删除。如果API严格是为了您的利益（即仅在您的公司内部使用），那么最好只是删除有问题的代码。从长远来看，它更清洁，并且将减少维护麻烦。

但是，如果API是面向公众的，则仅删除方法可能会导致用于库的旧版本的代码停止工作。那就是事情变得混乱的地方。以下是一些准则：

• 内部API：删除而不是弃用。如果任何客户端正在使用内部类或方法，则该工具损坏是他们的错。
• 外部API：先弃用，然后再删除。弃用是一个标志，表示以后将删除某些内容。以后取决于您认为合理的内容。在实际删除不赞成使用的代码之前，至少要提供2-3个版本。

在@deprecate类或方法时设置提醒可能是个好主意。您正在这样做以促进其过时。因此，请猜测一下，您需要多少时间才能消除所有参考，这是您的业余时间。将其标记为@deprecated，并在日历中添加提醒。收到提醒后，请检查。如果不再使用，请将其删除。如果剩下几个可以快速更新的参考，请执行此操作并删除该项目。如果还有更多重要的工作要做，请提前提醒一下。

这样做足够多的时间，您就会感到摆脱项目中的类或方法需要花费多长时间。

恕我直言，如果您可以确保没有人使用它并且永远不会使用它，只需将其删除。（在存在反射或外部组件（例如Velocity宏）的情况下，这可能很棘手-像IntelliJ这样的现代IDE可以在例如JSP中找到引用，但不能通过反射或Velocity找到。）

如果有更好的替代方法，但仍在许多地方使用旧的替代方法，并且您目前没有时间重构所有客户端代码，则@弃用过时的类/方法就足够了（对首选替代方法）。