网站查询功能 技术支持 中企动力,北京网站建设公司排行榜,网站远程图片,网站方案书几周前#xff0c;我们详细研究了默认方法 -Java 8中引入的一项功能#xff0c;该功能允许为接口方法提供实现#xff0c;即方法主体#xff0c;从而定义接口中的行为。 引入此功能是为了实现接口演进 。 在JDK的上下文中#xff0c;这意味着在不破坏所有代码的情况下向接… 几周前我们详细研究了默认方法 -Java 8中引入的一项功能该功能允许为接口方法提供实现即方法主体从而定义接口中的行为。 引入此功能是为了实现接口演进 。 在JDK的上下文中这意味着在不破坏所有代码的情况下向接口添加新方法。 但是尽管Java本身非常致力于保持向后兼容性但其他项目并不一定要做到这一点。 如果他们愿意他们可以以让客户更改代码为代价来开发接口。 在Java 8之前这经常涉及客户端编译错误因此可以避免更改否则客户端必须一次性迁移。 使用默认方法接口演变可以成为一个无错误的过程在此过程中客户端可以在版本之间留出时间来逐步更新代码。 这大大增加了开发接口的可行性并使其成为常规的库开发工具。 让我们看一下如何添加替换和删除接口方法。 未来的文章将探讨替换整个接口的方法。 总览 该帖子首先定义了一些术语然后介绍了添加替换和删除接口方法的方法。 它是从更改库中界面的开发人员的角度编写的。 我觉得该主题不需要示例因此我没有编写任何示例。 如果您不同意并希望看到一些内容请发表评论并且-在时间允许的情况下-我会写一些。 术语 接口具有实现和调用者 。 两者都可以存在于库中在这种情况下它们都称为internal 或者在客户端代码中称为external 。 这总共增加了四种使用界面的类别。 根据界面的发展方式和存在的用途必须采用不同的模式。 当然如果既不存在外部实现也不存在外部调用者则这些都不是必需的因此本文的其余部分假定这些情况中至少有一种确实存在。 接口演变–方法 因此让我们看看如何在不破坏客户端代码的情况下添加替换或删除接口方法。 通常可以通过执行以下过程来实现 新版本 该库的新版本已发布其中界面定义是过渡性的并结合了旧的和新的所需轮廓。 默认方法可确保所有外部实现和调用仍然有效并且在更新时不会出现编译错误。 过渡 然后客户就有时间从旧大纲过渡到新大纲。 同样默认方法可确保适应的外部实现和调用有效并且可以进行更改而不会编译错误。 新版本 在新版本中该库删除了旧轮廓的残差。 鉴于客户端明智地利用了自己的时间并进行了必要的更改因此发布新版本不会导致编译错误。 这个过程使客户能够按自己的时间表平稳地更新代码这使得接口的发展比以前更加可行。 Johanna Pung在CC-BY-SA 3.0下为Wikimedia Deutschland 发布 。 遵循以下详细步骤时请确保检查何时更新了内部和外部实现以及何时允许内部和外部调用者使用所涉及的方法。 确保在您自己的代码中遵循此过程并为您的客户正确记录下来以便他们知道何时执行操作。 Javadoc标签Deprecated和apiNote是实现此目的的好方法。 通常不必按该顺序执行过渡内的步骤。 如果是则明确指出。 如果您向客户提供可以在其界面实现上运行的测试则这些步骤中包含测试。 加 仅当存在外部接口实现时才需要此过程。 由于该方法是新方法因此当然尚未调用因此可以忽略这种情况。 区分是否可以提供合理的默认实现是有意义的。 存在合理的默认实现 新版本 为新方法定义测试 使用默认实现通过测试添加方法 内部呼叫者可以使用该方法 内部实现可以在必要时覆盖该方法 过渡 外部呼叫者可以使用该方法 外部实现可以在必要时覆盖该方法 无需执行任何操作也不需要任何新版本。 这就是Java 8中添加的许多新的默认方法所发生的事情。 不存在合理的默认实现 新版本 定义新方法的测试 这些必须接受UnupportedOperationExceptions 添加方法 包括一个引发UnupportedOperationException的默认实现通过测试 apiNote注释文档默认实现将最终被删除 在所有内部实现中覆盖该方法 过渡 必须按该顺序执行以下步骤 外部实现必须重写该方法 外部呼叫者可以使用该方法 新版本 测试不再接受UnupportedOperationExceptions 使方法抽象 删除默认实现 删除apiNote注释 内部呼叫者可以使用该方法 勉强一致的默认实现允许外部实现逐渐更新。 请注意在实际在内部或外部调用新方法之前将更新所有实现。 因此永远不会发生UnupportedOperationException。 更换 在这种情况下一种方法将被另一种方法替代。 这包括方法更改其签名例如其名称或参数数量的情况在这种情况下新版本可以看作是替换旧版本。 当存在外部实现或外部调用者时必须应用此模式。 仅在两种方法在功能上等效时才起作用。 否则就是添加一个功能并删除另一个功能的情况。 新版本 为新方法定义测试 添加新方法 包括调用旧方法的默认实现 apiNote注释文档默认实现将最终被删除 弃用旧方法 包括调用新方法的默认实现旨在进行循环调用如果存在默认实现则可以保留 apiNote注释文档默认实现将最终被删除 Deprecation评论文档说明将使用新方法 内部实现会覆盖新方法而不是旧方法 内部调用者使用新方法代替旧方法 过渡 外部实现会覆盖新方法而不是旧方法 外部呼叫者使用新方法代替旧方法 新版本 使新方法抽象 删除默认实现 删除apiNote注释 删除旧方法 尽管循环调用看起来很有趣但它们确保实现哪种方法都无关紧要。 但是由于这两种变体都有默认实现因此如果两种实现均未实现则编译器不会产生错误。 不幸的是这会产生无限循环因此请确保将其指出给客户。 如果您为他们的实现提供测试或者他们编写了自己的实现则他们会立即意识到这一点。 去掉 删除方法时根据是否存在外部实现可以应用不同的模式。 存在外部实现 新版本 方法的测试必须接受UnupportedOperationExceptions 弃用该方法 包括一个引发UnupportedOperationException的默认实现通过更新的测试 Deprecation注释文档表明该方法最终将被删除 apiNote注释文档说明默认实现仅存在于逐步淘汰方法中 内部呼叫者停止使用该方法 过渡 必须按该顺序执行以下步骤 外部呼叫者停止使用该方法 该方法的外部实现已删除 新版本 删除方法 请注意只有在不存在对该方法的更多调用之后才删除内部和外部实现。 因此永远不会发生UnupportedOperationException。 外部实现不存在 在这种情况下定期弃用就足够了。 仅出于完整性考虑而列出了这种情况。 新版本 用Depreated弃用该方法 内部呼叫者停止使用该方法 过渡 外部呼叫者停止呼叫方法 新版本 删除方法 反射 我们已经看到了如何通过添加替换和删除方法来实现界面演化新的界面版本结合了旧轮廓和新轮廓客户端从前者过渡到后者而最终版本则消除了旧轮廓的残留。 所涉及方法的默认实现确保客户端代码的旧版本和新版本都能正确编译和运行。 翻译自: https://www.javacodegeeks.com/2015/03/interface-evolution-with-default-methods-part-i-methods.html
