微服务开发系列：为什么选择 kotlin

源码地址

微服务开发系列：开篇
微服务开发系列：为什么选择 kotlin
微服务开发系列：为什么用 gradle 构建
微服务开发系列：目录结构，保持整洁的文件环境
微服务开发系列：服务发现，nacos 的小补充
微服务开发系列：怎样在框架中选择开源工具
微服务开发系列：数据库 orm 使用
微服务开发系列：如何打印好日志
微服务开发系列：鉴权
微服务开发系列：认识到序列化的重要性
微服务开发系列：设计一个统一的 http 接口内容形式
微服务开发系列：利用异常特性，把异常纳入框架管理之中
微服务开发系列：利用 knife4j，生成最适合微服务的文档

项目中采用的开发语言是 kotlin 。

开发人员可以根据自己需要采用 java 语言开发，但是很明显的，项目中各种工具类已经为了 kotlin 做出了很多修改，如果大量采用 java 开发， 结果可能是比纯 java 开发的速度还要慢。

至于为什么要坚持采用 kotlin 开发，之前我有发表过一些文章来描述 kotlin 好用的地方，但还是在使用过程中总会时不时的被 kotlin 惊艳一下。

kotlin 除了完全兼容 java 之外，还能够在架构中发挥不少优势，除了下面描述的地方，后面的介绍也会涉及。

极少的代码量

kotlin 将 java8 中的 stream 一系列的操作，都通过扩展特性，做了极大的简化。

例如 list 转 map users.associate { it.name to it}，就省略了大堆繁琐的代码。

编写代码过程中的智能推断变量类型，能够帮助你避免反复的推断类型，从而把自己绕晕。

对于传入匿名函数，能够避免手动创建函数对象。

对于空指针的 “?” 操作，能够极大简化对于空变量的判断处理。

等等，诸如此类的操作，如果能够完全掌握，就能够减少数倍的代码量，学习过概率学的应该明白，更少的动作达到相同的目的，自然发生问题的概率更小。

设计利器

减少代码量并不是 kotlin 的终点。

如果一个框架完全由 kotlin 搭建，只利用其特性来催促个别开发者写出更好的业务代码就太浪费了。

kotlin 还能够帮助你补全框架设计中的一些遗憾。

异常抛出

以框架设计中必不可少的业务异常抛出为例。

if (user.id.isNullOrEmpty()) {
    throw SomeException("user id cannot be empty")
}

这样的代码数不胜数，然而利用简单的扩展特性，就能够以新颖并且合理的方式抛出异常。

fun Boolean.ifSome(message: String?) = throw SomeException(message)

user.id.isNullOrEmpty().ifSome("user id cannot be empty")

这样除非在特殊情况下，否则框架中的任何地方都使用这种方式来抛出异常，即节省代码，又拥有更高的可读性。

这种方式目前 java 有一种工具manifold中的扩展功能也能够一定程度上实现这种方法。

更方便的 json 开发

在框架中封装了 jackson 的使用。

之前的版本，如果想要把 java 对象转换成 jackson 对象，都需要像这样：

val json = Jackson.toJavaObject(user)

于是在运用了扩展之后，创造出了更加好用的转换逻辑。

fun Any.toObject() = Jackson.convertObject(this)
fun Any.toArray() = Jackson.convertArray(this)
fun Any.jsonString() = Jackson.objectToString(this)
inline fun <reified T> Any.convert() = Jackson.convert(this, object : TypeReference<T>() {})

val user = User()
user.toObject()

在以后的使用中，任何对象自身都可以在 json 和 javaObject 之间自由的转换，这更加符合人们的思考逻辑。

kotlin 是否值得信赖？

有一些人对 kotlin 这个语言是否稳定有疑虑。

实际上这一点完全不需要考虑。

一款开发语言能够被发布出来，已经说明了一切。

你可能会说，kotlin 在一些极端的情况下，可能会有意料之外的表现，毕竟 koltin 是先编译成 java，因此在复杂的情况下，会出现一些问题。

对此我想说，没有一款语言能够避免这一种情况，对编译器有一定了解的人，能够针对编译器的编译方式，做写一些匪夷所思的让编译器出错的程序。

就连 java 本身也有一些 bug，你应该在网上遇到过很多关于 jvm bug 的分析。

虽然这种问题在正常的开发流程中可能会出现，但是是 kotlin 的原因吗？

很明显不是，因为没有语言能避免，甚至有些不合理的地方都不能称之为 bug，而是特性。

许多人对 jvm 本身都谈不上了解的有多深入，更加没有去怀疑 kotlin 的理由。