如何避免Kotlin里的陷阱?

开发 后端
最近 Kotlin 特别流行,并且我也赞同 Kotlin 是一个经过深思熟虑后被设计出的语言,除了下面提到的缺点之外。我会在本文向你分析一些我在开发过程中遇到的陷阱,并且教你如何避免他们。

最近 Kotlin 特别流行,并且我也赞同 Kotlin 是一个经过深思熟虑后被设计出的语言,除了下面提到的缺点之外。我会在本文向你分析一些我在开发过程中遇到的陷阱,并且教你如何避免他们。

[[207040]]

谜一样的 null

在 Kotlin 当中,你可以不用考虑在你的代码中如何处理 null 的问题,这会让你忘记 null 是无处不在的这个说法,只不过被隐藏了起来。看看下面这个表面看起来没有问题的类: 

  1. class Foo { 
  2.     private val c: String 
  3.     init { 
  4.         bar() 
  5.         c = "" 
  6.     } 
  7.     private fun bar() { 
  8.         println(c.length) 
  9.     } 

如果你尝试初始化这个类,那么代码就会抛出一个 NullPointerException。因为 bar 方法尝试在 c 变量初始化之前就访问它。

尽管这个代码本身就是有问题的,才导致异常抛出。但是更糟糕的是你的编译器不会发现这一点。

Kotlin 可以帮你在绝大部分情况下避免 null,但是你不能因此而忘记 null 的存在。否则迟早有一天你会碰上类似的问题。

来自 JDK 的 null

Kotlin 的标准库能够很好地处理 null。但是如果你使用了 JDK 中的类,你需要自己处理关于 JDK 方法调用可能产生的空指针。

大部分情况下 Kotlin 的标准库就足够了,但是有时你需要使用到 ConcurrentHashMap: 

  1. val map = ConcurrentHashMap<String, String>() 
  2. map["foo"] = "bar" 
  3. val bar: String = map["foo"]!! 

这时,你需要使用 !! 操作符。但某些情况下你还可以使用像 (?) 这样的对 null 安全的操作符来替换它。尽管如此,当你使用 !! 或者 ? ,或者编写了一个适配器来使用 Java 类库的时候,你会发现代码因为这些修改而变的混乱。这是你无法避免的问题。

你还可能会碰上更多更可怕的问题。当你使用 JDK 类中的方法的时候,返回值可能是null,而且没有什么像 Map 访问一样的语法糖。

考虑如下例子: 

  1. val queue: Queue<String> = LinkedList() 
  2. queue.peek().toInt() 

这种情况下,你使用了可能返回 null 值的 peek 方法。但是 Kotlin 编译器不会提示你这个问题,所以当你的 Queue 是空队列的的时候,可能会触发 NullPointerException 异常。

问题在于我们使用的 Queue 是 JDK 的一个接口,并且当你查看 peek 方法的文档时: 

  1. /** 
  2.   * Retrieves, but does not remove, the head of this queue, 
  3.   * or returns {@code null} if this queue is empty. 
  4.   * 
  5.   * @return the head of this queue, or {@code null} if this queue is empty 
  6.   */ 
  7.   E peek(); 

文档中说 peek 方法会返回一个 E 类型的对象,但是 Kotlin 认为 E 是不可空的。在接下来的 Kotlin 版本中可能会解决这个问题,但是现在当你在你的工程中使用类似接口的时候,一定要注意: 

  1. val queue: Queue<String?> = LinkedList() 
  2. queue.peek()?.toInt() 

内部 it

当一个 lambda 表达式只有一个参数的时候,你可以在你的代码中将其省略,并用 it 代替。

  • it:单参数的内部名称。当你表达式只有一个参数的时候,这是一个很有用的特性,声明的过程可以省略(就像 ->),并且参数名称为 it。

问题是,当你的代码中存在向下面例子一样的嵌套函数的时候: 

  1. val list = listOf("foo.bar""baz.qux"
  2. list.forEach { 
  3.     it.split(".").forEach { 
  4.         println(it) 
  5.     } 

it 参数会混淆。解决方法就是像下面这样显示的声明: 

  1. list.forEach { item -> 
  2.     item.split(".").forEach { part -> 
  3.         println(part) 
  4.     } 

看起来是不是好多了!

隐藏的复制

注意观察下面的类:

  1. data class Foo(val bars: MutableList) 

data 类提供了一系列的方法,并且你可以通过拷贝得到其镜像。猜猜下面的代码会输出什么? 

  1. val bars = mutableListOf("foobar""wombar"
  2. val foo0 = Foo(bars) 
  3. val foo1 = foo0.copy() 
  4. bars.add("oops"
  5. println(foo1.bars.joinToString()) 

 控制台会输出 foobar, wombar, oops。问题出在 copy 方法并没有真正地复制一个完整的对象, 而是复制了对象的引用。当你忘记编写单元测试类,并且将你的 data 类按照不可变类来传递的时候,就可能出现这种问题。

解决方法就是当你使用 data 类的时候一定要多加小心,并且当你必须将其作为值对象的时候,像下面这样:

  1. data class Foo(val bars: List) 
  • data 类还有一个问题:其 equals / hashCode 方法所用到的属性不可变。你只能通过手工重写这些方法的方式来修改返回值。谨记上面这一点。

内部方法暴露

仔细思考下面的例子: 

  1. class MyApi { 
  2.     fun operation0() { 
  3.     } 
  4.     internal fun hiddenOperation() {             
  5.     } 

当你在 Kotlin 的项目中引用这个类的时候,internal 关键字是生效的。但是当你从一个 Java 项目中使用的时候,hiddenOperation 就变成了一个公共方法!为了避免这种情况,我建议使用接口的方式来隐藏实现的细节: 

  1. interface MyApi { 
  2.     fun operation0() 
  3. class MyApiImpl: MyApi { 
  4.     override fun operation0() { 
  5.     } 
  6.     internal fun hiddenOperation() { 
  7.     } 

特殊的全局扩展

毫无疑问,扩展函数的功能非常重要。但通常,能力越大责任越大。例如,你可以编写全局的 JDK 类扩展函数。但是当这个函数只在本地上下文中有意义,却是全局可见的时候,就会带来很多麻烦。 

  1. fun String.extractCustomerName() : String { 
  2.     // ... 

每个跳转到你的方法的人都会不知所措。所以我认为在你编写这样的方法之前务必三思。下面就是一个建议: 

  1. /** 
  2.  * Returns an element of this [List] wrapped in an Optional 
  3.  * which is empty if `idx` is out of bounds. 
  4.  */ 
  5. fun <T> List<T>.getIfPresent(idx: Int) = 
  6.         if (idx >= size) { 
  7.             Optional.empty() 
  8.         } else { 
  9.             Optional.of(get(idx)) 
  10.         } 
  11. /** 
  12.  * Negates `isPresent`. 
  13.  */ 
  14. fun <T> Optional<T>.isNotPresent() = isPresent.not() 

lambdas Unit 返回值 vs Java SAM 转换

如果你的函数参数是 lambdas 表达式,并且返回值类型是 Unit 的时候,你可以省略return 关键字: 

  1. fun consumeText(text: String, fn: (String) -> Unit) { 
  2. // usage 
  3. consumeText("foo") { 
  4.     println(it) 

这是一个很有趣的特性,但是当你在 Java 代码中调用该方法的时候会比较尴尬: 

  1. consumeText("foo", (text) -> { 
  2.     System.out.println(text); 
  3.     return Unit.INSTANCE; 
  4. }); 

这对于 Java 端来说是不友好的,如果你想在 Java 中成功调用该方法,你需要定义如下接口: 

  1. nterface StringConsumer { 
  2.     fun consume(text: String) 
  3. fun consumeText(text: String, fn: StringConsumer) { 

然后你就能使用 Java 的 SAM 转换。

  1. consumeText("foo", System.out::println); 

但是在 Kotlin 这边看起来就很糟糕了: 

  1. consumeText("foo", object: StringConsumer { 
  2.     override fun consume(text: String) { 
  3.         println(text) 
  4.     } 
  5. }) 

问题关键点在于只有 Java 支持 SAM 转换,Kotlin 并不支持。我的建议是简单的场景中,只是用 Java 的 SAM 接口作为一个消费者: 

  1. fun consumeText(text: String, fn: Consumer<String>) { 
  2. // usage from Kotlin 
  3. consumeText("foo", Consumer { 
  4.     println(it) 
  5. }) 
  6. // usage from Java 
  7. consumeText("foo", System.out::println); 

Java 中使用不可变集合

Kotlin 提供了 JDK 集合类的不可变版本。 

  1. fun createSet(): Set<String> = setOf("foo"
  2. // ... 
  3. createSet().add("bar") // oops, compile error 

这是一个很好的补充。但是当你在看 Java JDK 的 Set 类 API 的时候会发现:

  1. createSet().add("bar"); // UnsupportedOperationException 

当你尝试修改这个 Set 的时候,就会抛出这个异常,就像你使用了Collections.unmodifiableSet() 方法一样。我不知道这种情况是否合理,但是你在使用 Kotlin 不可变版本的 Java 集合类的时候,需要谨记这一点。

接口中没有重载

Kotlin 在接口上不支持使用 @JvmOverloads 注解,当然 override 也不行。 

  1. interface Foo { 
  2.     @JvmOverloads // OUCH! 
  3.     fun bar(qux: String) 
  4. class FooImpl : Foo { 
  5.  
  6.     @JvmOverloads // YIKES! 
  7.     override fun bar(qux: String) { 
  8.     } 

你只能像下面这样手动定义: 

  1. interface Foo { 
  2.     fun bar() 
  3.     fun bar(qux: String) 

要记住你可以使用 Kotlin 中的 KEEP (Kotlin Evolution and Enhancement Process) 来改善。KEEP 与 Java 中的 JEP 类似,但是与 JEP 相比要简洁许多。

总结

Kotlin 现下很流行,并且我也认为他是一个增强版的 Java。但是在使用 Kotlin 的时候你仍需要保持清醒,尤其是当你身处各种各样的关于 Kotlin 的宣传之中时。如果你要使用 Kotlin 的话,一定要注意我们在上面提到的 Kotlin 相关的缺陷。

***我还是想说,上述提到的问题都比较容易解决,并且不会对语言的使用方面带来本质性的伤害。

责任编辑:未丽燕 来源: 程序师
相关推荐

2021-03-01 15:52:14

开源开源软件陷阱

2018-06-11 15:26:47

云计算企业云陷阱

2021-04-22 11:22:12

云计算数据迁移混合云

2019-02-11 10:00:23

云网络云平台微服务

2022-09-19 09:19:24

云存储TCO云服务

2014-07-11 10:23:54

2015-06-02 11:10:20

2011-06-07 15:34:15

2024-03-04 13:23:00

数字化转型

2022-03-17 18:26:42

微前端

2022-10-11 07:20:56

YAML字符串语言

2013-06-21 10:15:33

BYOD

2021-07-16 10:27:07

ITIT领导IT管理

2013-01-06 10:15:02

大数据分析数据分析师大数据

2024-03-04 07:50:04

Python字符编码网络通信

2024-01-22 08:20:40

Python编程语言代码陷阱

2023-10-04 07:38:20

架构架构设计领域

2018-11-18 16:31:14

Kubernetes监控容器

2021-02-28 13:19:42

大数据IT数据管理

2021-10-22 06:05:29

SD-WAN网络架构网络
点赞
收藏

51CTO技术栈公众号