java中的生命周期_Java中的功能生命周期

java中的生命周期

今天，我想解决一个似乎被相当一部分Java开发人员误解的主题：Java功能的生命周期。

产品管理101

在专注于Java之前，让我们先进行一般性的讨论。 假设您设计一种语言，一种框架，一种库，提供给第三方的任何东西。 由于您做得很好，因此该软件现已得到广泛使用。

因为这是真实世界，所以一段时间后，您意识到所提供的特定功能还不够好。 我们将此功能称为feature-v1 。 您做得很好，很好地将API与实现细节分开。 如果这是一个简单的错误，那将很容易：只需更改实现细节，就可以完成。 但事实并非如此。 问题出在API。 而且该API已被许多用户使用。

因此，您不能仅用改进的功能替换该功能。 我们将此称为功能v2 。 这样做会阻止用户轻松迁移到新版本。 您需要在保持feature-v1的同时添加feature-v2 。 这样，用户可以升级并从其他方面的改进中受益，而无需更改其代码库。 这是向后兼容 。

这样，您希望用户能够慢慢迁移到feature-v2，因为它要好得多。 不幸的是，这似乎没有发生。 至少不符合您的预期。 更糟糕的是，一些新用户似乎不了解feature-v2的功能 ，而不是feature-v1的值 ，他们使用了它。 就在您准备交付功能v3的同时 ！ 它开始成为维护的噩梦：当然，与该功能相关的成本正在上升。 但是大多数软件开发人员都希望使用最新版本，而不是旧版本的维护...

那不可能持续很长时间。 要做的第一步是阻止新用户使用feature-v1 。 尽管这本身不能避免，但至少应告知他们： feature-v1不是最新的也是最大的。 此过程称为弃用 。 这是对每个人的大胆而明确的声明，至少在当前形式下，功能版本没有未来。

最后，一段时间后，你可以删除功能-V1：显然，这是已知的去除 。

Java中的弃用

标记类或类成员不赞成使用的原始方法是通过JavaDoc标记。 实施方法如下：

/**
 *  @deprecated As of release 1.1, replaced by {@link #bar()}
 */
publicvoidfoo(){}

这种方法有几个局限性：

1. 如果您没有访问JavaDocs的权限，那么您也就没有弃用信息。 例如，如果您使用Maven和IDE，则必须配置IDE以下载JavaDocs和二进制JAR。 尽管它是一次性配置，但许多开发人员却不这样做
2. 这取决于JavaDocs的整体质量。 如果您已经使用了一些长期存在的库/框架，那么@deprecated可能会绊倒不止一次，而没有任何更多信息。

   /** @deprecated */
   publicvoidfoo(){}

   祝你好运，知道要用什么...

Java 5与注释一起带来了@Deprecated 。 一方面，它具有运行时保留策略。 因此，它可以与二进制文件一起访问。 另一方面，它不能解决质量问题。

Java 9中包含的JEP 277试图改善这种情况。 不幸的是，最后，它仅向@Deprecated添加了两个属性：

public@interfaceDeprecated{
    Stringsince()default"";
    booleanforRemoval()defaultfalse;
}

那也不能解决质量问题。

用Java移除

很长一段时间以来，Java中都没有删除任何功能。 不是一个。 齐尔奇 仅弃用。 例如，您仍然可以检查java.util.Date ：它具有自Java 1.1仍然存在和生效以来不推荐使用的方法。 该版本于1997年发布。想象一下！

恕我直言，这种向后兼容的长期方法是Java在企业中如此成功的主要原因之一。 不利的一面也是年轻的语言能够更具创新性的原因之一。 用户群越大，向后兼容性就越重要。

实际上，仅从Java 9开始才删除API（就我所知，如果我错了，请纠正我）。 也计划在Java 10中删除一些API 。

结论

管理功能的生命周期并不容易。 必须在创新和向后兼容性之间取得良好的平衡。 下次您想让Java缺少通用化泛型时，请考虑以上所有内容。

更进一步：

• 如何以及何时弃用API
• JEP 277“增强弃用”非常好。 但这是一个更好的选择

翻译自: https://blog.frankel.ch/feature-lifecycle-java/

java中的生命周期