Java 到 Kotlin

第 2 章 从 Java 到 Kotlin 项目 Java 到 Kotlin 项目

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

从纯 Java 到混合，再到越来越多的 Kotlin 代码库的第一步是什么？

战略

我们（Nat 和 Duncan）第一次将 Kotlin 引入 Java 代码库时，我们是一个小团队的成员，其中包括六名开发人员，正在构建一个相对全新的项目。我们已经用 Kotlin 部署了一些 Web 应用程序，但我们的企业架构师坚持让我们用 Java 8 编写新系统。当时 Kotlin 1.0 刚刚发布不久，但谷歌还没有宣布将 Kotlin 作为 Android 的官方语言，因此架构师们对于将一种前途未卜的语言用于他们预计会存在几十年的战略系统持谨慎态度，这是可以理解的。

在 Java 中，我们倾向于采用函数式方法，将核心应用领域模型设计为通过管道转换的不可变数据类型。 然而，我们不断遇到 Java 的限制：实现不可变值类型所需的冗余度、基元类型和引用类型之间的区别、空引用以及缺乏常用高阶函数的 Streams。 与此同时，我们看到 Kotlin 在整个行业甚至在公司内部的采用率越来越高。 当我们看到 Google 的公告时，我们决定开始将我们的 Java 转换为 Kotlin。

我们的判断是，从核心领域模型入手将给我们带来最大的收益。 Kotlin 的数据类极大地缩减了代码，在某些情况下，只需一个声明就能替换掉数百行代码。 我们小心翼翼地开始工作，使用 IntelliJ 转换了一个小的值类，除了标准库中的类之外，该类与其他类没有任何依赖关系，我们还检查了这对 Java 代码库中其他类的影响。 结果完全没有影响！有了这次成功的经验，我们加快了步伐。 每当有新功能需要修改 Java 领域模型类时，我们都会先将其转换为 Kotlin 数据类，提交转换，然后实现该功能。

随着越来越多的领域模型逻辑变成纯 Kotlin，我们能够更好地利用 Kotlin 功能。 例如，我们用 Kotlin 的集合和序列标准函数取代了对 Stream API 的调用。 不过，最大的改进是用可空引用取代了 Java 的可选类型。 这简化了我们的代码，并让我们对其空安全性更有信心。

公司的另一个项目采用 Kotlin 则是出于另一个原因。 他们有一个基于依赖注入框架构建的成熟 Java 系统。 开发人员发现，该框架对反射和注解的使用使得代码难以理解，也难以在集成开发环境中浏览。 Kotlin 的轻量级闭包语法提供了一种方法，可以定义应用程序的结构，并区分为整个应用程序、每个 HTTP 请求或每个数据库事务实例化的对象图。 他们逐渐重构了系统的基础，从一个掩盖架构的框架转变为一种由函数组成的风格，使架构在代码中清晰可见。 这项工作成为了http4k网络编程工具包。

正如这两个例子所示，起点的选择应取决于多种因素，包括团队采用 Kotlin 的原因、代码库的规模以及变化的频率。 你了解自己的项目，可以决定哪些是最需要改变的。

如果你是为了 Kotlin 的语言特性而选择它，那么像我们在第一个项目中所做的那样，转换你最常使用的类是有意义的；如果你是为了使用某个特定的库而选择 Kotlin，那么针对 API 开始编写 Kotlin 代码，对其进行注释以方便你的 Kotlin 代码与应用程序其他部分中的 Java 代码兼容，然后再继续编写下去，这样做也是有意义的；如果你是为了使用某个特定的库而选择 Kotlin，那么针对 ...