回答。

質問の歴史:

sealed修飾子を持つインターフェースは、Kotlinのsealed classの概念に基づいて登場しました。Kotlin 1.5以前は、sealedクラスのみが可能な派生クラスのセットを制限することを許可しており、これは状態遷移マシンやDSLなどの状態階層を安全に扱うために特に重要です。sealedインターフェースを導入することで、開発者はクラスに依存せずにインターフェースの実装を同様に制限することができるようになりました。

問題:

オープンなインターフェースはプログラムのどこでも実装できるため、実装の数が制御不能に増加し、コードの保守が複雑になることがあります。when式を通じて処理する際、コンパイラは未処理の分岐について警告できません。

解決策:

sealed interfaceは、同じモジュール内で定義された実装にのみ制限します（インターフェースがトップレベルでない場合は同じファイル内に）。これは安全なenumのような構造、ADTパターン、状態ハンドラーに対する制御の一形態です。コンパイラはすべての実装を知っており、コード解析を助けます。

コード例:

sealed interface NetworkResult

class Success(val data: String): NetworkResult
class Error(val cause: Throwable): NetworkResult
object Loading: NetworkResult

fun handleResult(result: NetworkResult): String = when (result) {
    is Success -> "Success with ${result.data}"
    is Error -> "Error: ${result.cause.message}"
    Loading -> "Loading..."
}

主な特徴:

Sealedインターフェースは実装数の制限を提供し、type-safetyを向上させます。
when式で動作する：コンパイラは網羅性をチェックします。
実装はクラスやオブジェクト、他のsealedタイプであることができますが、同じモジュール内に限ります。

トリックのある質問。

現在のファイルの外でsealed interfaceを実装できますか？

回答：sealedクラスとは異なり、sealedインターフェースは他のファイルで実装することができますが、同じモジュール内に限られます（インターフェースがトップレベルでない場合は、コンパイルユニット内に限る）。

sealed interfaceはデフォルト実装を持つオープンメソッドを持つことができますか？

はい、通常のインターフェースと同様に、sealedインターフェースは関数のデフォルト実装を含むことができます。

sealed interface Mode {
    fun description(): String = "Unknown mode"
}

標準のシリアライザー（例えば、kotlinx.serialization）を使用してsealed interfaceをシリアライズすることは可能ですか？

可能ですが、すべての実装を明示的に指定する必要があります。Kotlinx.serializationではsealedインターフェースのサポートはすぐには行われませんでしたので、シリアライズ可能なタイプを明示的に指定することが重要です。

一般的なエラーとアンチパターン

モジュールの外で実装を定義する
オプションが少なく構造が単純な場合にenumの代わりにsealedインターフェースを過剰に使用する
sealed interfaceを更新する際に網羅性チェックを行わない

実生活の例

ネガティブケース

プロジェクトで全てのUI状態タイプについてsealedインターフェースを定義したが、実装はアプリケーションの異なる部分に現れ始めた。後で新しい状態タイプを追加する際に、処理ブロックの更新を忘れたため、新しい状態がログで無視される結果になった。

利点:

新しい状態の迅速な追加

欠点:

type-safetyが低下し、ロジックに考慮されていない分岐が現れる

ポジティブケース

全てのネットワークレスポンスにsealedインターフェースを使用した。その結果、新しいレスポンスタイプを追加すると、IDEは配列されたすべてのwhenブロックで処理が強調表示された。エラーは即座に修正され、ロジックに予期しない穴がありません。