modularization について
Kotlin のマルチモジュールプロジェクト向けに、実際の利用範囲に応じた可視性の設定方法を示すリファレンスです。公開 API とモジュール内部の実装を分け、API の範囲を不必要に広げない考え方を扱います。
主な機能
- 01コンパイル可能な最小範囲の可視性
- 02公開インターフェースと内部実装の分離
- 03モジュール内ヘルパーへの internal の使用
- 04クラス内メンバーへの private の使用
- 05別モジュールからの利用を公開判断の基準にする
活用シーン
- 01モジュールの公開インターフェース定義
- 02Mapper や拡張関数の可視性制限
- 03マルチモジュールプロジェクトの API 範囲の見直し
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ rcosteira79/ android-skills --skill modularizationインストール後、Claude Code で/modularizationを入力して読み込まれたか確認します。
詳細
モジュール化
コンパイルに必要な範囲で、最も可視性の低い修飾子を指定します。 まず private にし、同じ モジュール 内の別ファイルから必要な場合に限り internal に広げます。さらに、別のモジュール が実際に使用する場合に限り public に広げます。Kotlin のデフォルトは public ですが、マルチモジュールプロジェクトでは通常、このデフォルトは適切ではありません。public のシンボルはモジュールの API サーフェスに加わり、モジュール境界を越えて実装が漏れるため、その安定性を維持する義務が生じます。
- モジュールの API として公開するインターフェース → インターフェースは
publicにします。実装クラスはinternalのままにします(DI でバインドし、別のモジュールから名前を指定することはありません)。 - モジュール内でのみ使用するマッパー/ヘルパー/拡張機能/定数/UI 状態保持クラス →
internalにします(単一ファイルでのみ使用する場合はprivateにします)。「このモジュール内のコンポーザブルで描画される」ことは、publicにする理由にはなりません。internalであればモジュール全体から参照できます。 - クラス内でのみ使用するメンバー →
privateにします。
シンボルを public に広げるのは、デフォルトではなく判断を要する選択です。まず、モジュールをまたいで実際に使用する箇所があることを確認してください。
コメント
Markdown 対応