OkHttp: Java to KotlinのPRを見て勉強する

OkHttpがKotlin化をするというISSUEが立てられました。 Upgrade OkHttp 3 to Kotlin and call it OkHttp 4

これの是非についてはさておき。現状、いくつかのJavaコードがKotlinへと置き換わっているので、それらのレビューで気になったこと、知らなかったこと、忘れがちなことを勉強がてらまとめたいと思います。

checkNotNullを使うかどうか

could also be code no preference myself

Kotlinの標準ライブラリに、checkNotNullがあります。 これは、値がnullならIllegalStateException例外を投げるものです。

以下のコードは同じ意味を持ちます。

val state = someState ?: throw IllegalStateException("State must be set beforehand")

val state = checkNotNull(someState) { "State must be set beforehand" }

ただ、no preference myselfと言っている通り、使うかどうかはプロジェクトで分かれそうです。 事前に使うかどうかを、決めておくと揉めなく良さそうだと思いました。

命名はto***が慣用的

idiomatic naming would be toUrl on the Kotlin side

OkHttpでは、HttpUrlをURLに変換するためのメソッドとしてfun url(): URLが定義されています。しかし、fun toUrl(): URLのほうがKotlinっぽいよと指摘がありました。

確かに、言われてみるとAtoBクラス変換のメソッド名は、to***が多い気がします。ただし、今回は下位互換を保つために、一旦この修正は入りませんでした。

constを使う

discussion link

constを使うと、Compile Time Constantsとなり、付けない場合に比べ効率的に動作します。ただし、プリミティブか、String型のみに有効です。

より詳しくは公式ドキュメントで。

constを付けたほうが良いことは知っていたのですが、公式ドキュメントを読んだことがなかったので勉強になりました。

事前計算済みプロパティにのみ依存している場合は、事前計算済みプロパティにを使う

scheme is a val, so this can just be a precomputed property without the get()

isHttpsプロパティは最初、get()で定義していたんですが、isHttpsで使っているschemeプロパティがvalなので、get()が取り除かれました。

事前計算出来るプロパティは事前に計算しておく方針のようです。そのほうが、無駄なメソッドが定義されないので、良いという判断なのでしょうか?

プロパティ + get:JvmNameはより慣用的

property + @getJvmName(“size”) seems more idiomatic

単純かつ副作用がない関数はプロパティのほうがKotlinっぽいです。さらに、@get:JvmNameを使うことで、Javaからスムーズに使うことが出来ます、

fun size(): Int = encodedNames.size

@get:JvmName("size")
val size get(): Int = encodedNames.size

まとめ

今回の記事を書くために調べたコミット

Written by