交换库的常用方法

Question

我正试图想出一个解决方案，在我们的产品中用java 8 time代替joda-time。代码库包含许多项目，其中一些是直接导入joda时间的，有些是临时的。为了限制回归和为任务分配多个开发人员，需要一种迭代的库交换方法。这类任务的最佳实践是什么？

凭直觉，我将开始从依赖树的顶部向下移动到3-5项目组的根，同时为最低的项目编写临时包装器。接下来，运行集成测试，在成功的情况下，采取另一组项目，删除临时包装并重复。

还有其他选择吗？

Answer 1

不幸的是，Java语言的设计并不能轻松地交换依赖项。虽然可以使用接口包装外部依赖项并执行一些依赖项注入，但不能使用简单的类型别名。

理想情况下，您可以通过跨项目进行搜索和替换来完成大量迁移。因为这比较容易，所以如果不使用迭代方法，至少可以尝试一下。

否则，请查看您控制的组件的依赖关系图，并查看哪些部分是相当独立的，易于迁移。您必须在API边界上的时间库之间进行转换：

• 可以保留旧API，并在方法中转换任何参数/返回值。
• 您可以更改API并在调用位置进行转换。
• 有时您可以两者兼得:将方法迁移到新的API，但提供与旧API兼容的包装器。

使用哪种方法取决于：

• 如果在许多地方都使用了一个方法，那么使用兼容性包装器方法可能会更容易，这样您就可以一次迁移一个调用站点。
• 如果您不想在这个迭代中接触其他组件，请保留旧的接口--但这意味着您必须在第二步中再次触摸这段代码。
• 否则，只需做您需要的事情，并修复调用站点，直到它正常工作为止。

自上而下或自下而上的方法都可以。上述API边界视图具有自下而上的观点，但在这两种情况下都适用相同的原则。我认为，自下而上的集成将导致您不得不编写更少的兼容性包装器，您将不得不在以后删除。然而，这在很大程度上是你必须做出的判断。

如果某些组件是紧密耦合的，那么将它们迁移到一起是很有意义的。

在任何情况下，您都可能希望编写一个实用工具类，以帮助在这两种表示之间进行转换。