2016/10/02 このエントリーをはてなブックマークに追加 はてなブックマーク - 【Kotlin】ktファイルとパッケージ。Exceptions.ktとかの話

【Kotlin】ktファイルとパッケージ。Exceptions.ktとかの話




GitHub上のKotlinソースを眺めているとたまに1ファイルで複数のクラスを扱っていることがあります。


例えば以下のようなExceptions.ktとか。
https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/io/Exceptions.kt


ファイル名を複数形にし、その中に複数のExceptionクラスが実装されています。


こういう方法は割と見ます。

これの使いどころとかどうすべきなんだろう、という考察です。




このやり方をみて、「おお、これはKotlin知ってる素振りが出来るな」と
嬉々としてExceptions.kt的な書き方を僕はよくしていました。

Exceptionぐらいにとどめておくのが現実的です。あと、Enumとか。
例えば、僕は

  • AlertSupport
  • DownloadSupport
  • FrameSupport
  • NavigateSupport
  • InteractionSupport

と言ったクラスをSupports.ktとしていたのですが正直関数が複数個持つこれらのクラスを1つのファイルで管理するのはかなり見通しが悪くなり、「1つの巨大なクラス」と大差無いものになってしまいました。

これはメンテ出来んわ。。となってさっきパッケージを切ったりファイルを分けたりしていました。
https://github.com/yyYank/Kebab/tree/master/src/main/kotlin/support

これまた、色々GitHub上を眺めていると関数を集めたようなものを小文字始まりのクラスとしてつくっているものも結構見ました。

クラスではなくトップレベルの関数をnamespaceごとに管理したいという試みだと思います。
これはこれでありかなぁ、と思いつつもJavaやってると小文字始まりのファイルにはやや抵抗があったりする。。

MarioAriasCさんとかのはなんだかうまいやり方に見えます。
https://github.com/MarioAriasC/funKTionale/blob/master/src/main/kotlin/org/funktionale/collections/namespace.kt
namespace.ktがいっぱいあるんですよね。

KodeinのforClass.ktとかはクラス操作をしたい場合の関数のみ集めています。
https://github.com/SalomonBrys/Kodein/blob/master/kodein/src/main/kotlin/com/github/salomonbrys/kodein/forClass.kt

Scalaと同様、Kotlinは実際のpackage構成とpackage宣言の整合性がとれていなくても問題ありません。

何を言ってるかというと、

└── src
    └── main
        └── kotlin
            └── hoge
                └── Hoge.kt

とあって

package fuga

class Hoge{
}

とかしてもコンパイルエラーにならないということです。

今のところ、僕はこれのメリットが全然分かっていなくて、
素直に

└── src
    └── main
        └── kotlin
            └── hoge
                └── Hoge.kt

なら

package hoge

class Hoge{
}

とした方が良いと思います。

例えばnamespaceにprefixをつけたいとかなら有用なのかなぁという気もしますが。

└── src
    └── main
        └── kotlin
            └── hoge
                └── Hoge.kt

package oreoreframework.hoge

class Hoge{
}

とか。

ktファイルの分割、命名、packageの分割とかを考えてみました。
Kotlinは僕の知る限りだとこのあたりの命名規約とかが明記されてるドキュメントが無いと思います。

基本的にJavaに倣う感じで言語仕様に沿っていてみんな自然とこの形に行き着いたのではないかなぁ。
あとは、JetBrainsのKotlin関連のリポジトリ真似たりとかしてるのかもしれませんね。

Kotlinを業務導入しているところも結構あると思いますので、
「自分のプロジェクトのコーディング規約はこうだ」とか知れると僕としては楽しいですし、みんな喜ぶかもしれません。

0 件のコメント:

コメントを投稿