Java から Kotlin へ

第8章. 静的メソッドからトップレベル関数へ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

スタンドアロン関数はソフトウェアの基本的な構成要素の1つである。 Javaではクラスのメソッドとして宣言しなければならないが、Kotlinではトップレベルのエンティティとして宣言することができる。 どのような場合にトップレベル関数を使うべきなのか、Javaからどのようにリファクタリングすればよいのか。

Javaスタティクス

Java では、メンバー値をフィールド、メンバー関数をメソッドと呼び出す。 デフォルト値では、フィールドの値はクラスのインスタンス単位であり、インスタンスが異なれば値も異なる。 メソッドもインスタンス単位であり、呼び出されたインスタンスの状態にアクセスできる。 しかし、フィールドをstatic 、クラスのすべてのインスタンス間で共有される。静的メソッドはこの共有された状態（および他のクラスの可視静的フィールド）にしかアクセスできないが、この制限の代わりに、クラスのインスタンスを必要とせずにメソッドを呼び出すことができる。

Javaを単純化するために、言語設計者はすべてのコードとデータをクラスに縛り付けた。 クラスにスコープされた静的ステートがあるのだから、クラスにスコープされた静的メソッドが必要だ。 独立したデータや関数を追加することもできたが、静的フィールドとメソッドで十分だ。 言語にオプションがあれば、開発者はそのどちらかを選ばなければならなくなるが、選択肢は少ないほうがいいことが多い。 設計者はこの言語設計の決定をJava仮想マシンに引き継いだが、Java仮想マシンにはトップレベルのコードやデータを表現する手段がない。

静止状態

Java黎明期には、静的状態は今よりもずっと一般的だった。 私たちはシングルトンを書き、遅延しつつも安全な方法で初期化する方法について議論した。 インスタンスのクラスごとのキャッシュを実装するために静的フィールドを使った。 その後、新しいミレニアムのテスト・コードの流行によって、静的状態はほとんど使われなくなった。 というのも、あるテストと別のテストがステートによって結合されている場合、それらを分離するのは非常に難しいし、そのステートが静的でJVM内のすべてのテスト間で共有されている場合、それらの結合を解除するのは非常に難しいからだ（ここでいうステートとは可変性データのことであることに注意）。不変性データである定数はあまり問題にならない)。

そこで私たちは、そうでなければ静的状態をオブジェクトフィールドに保持することを学び、依存性注入を使用して、アプリケーション内でオブジェクトの共有インスタンスが1つだけになるように手配した。 (ここで「依存性注入」と言うとき、著者たちはフレームワークを使用するのではなく、「コンストラクタにオブジェクトを渡す」ことを意味している)。

この章では、状態よりもコードに焦点を当てる。

静的メソッドと非静的メソッドの両方が同じ型に作用するクラスがあることもある。たとえば、第3章で見た静的解析メソッドを持つEメールクラスなどだ。しかし、静的メソッドだけで構成されたクラスができることもよくある。共有する静的状態がない場合、これらのメソッドは実際には、java.util.Collections クラスのメソッドのように、クラス名を介して呼び出される、グループ化された独立した関数にすぎない： ...