【ITニュース解説】Your Sealed Class Cookbook: 3 Production-Ready Android Recipes

ソフトウェア開発、特にAndroidアプリケーション開発において、コードをより堅牢で理解しやすく、そして保守しやすいものにするための強力な機能として、Kotlinの「sealed」クラスやインターフェースが挙げられる。sealedは、特定の型が取りうる状態やサブタイプをあらかじめ限定することで、コンパイラがそれらのパターンを網羅的にチェックするのを助ける。これにより、実行時に予期せぬ状態が発生するリスクを減らし、開発者はより安心してコードを書けるようになる。ここでは、sealedクラス/インターフェースを実際にアプリケーション開発に役立てる具体的な方法と、注意すべき点について解説する。

まず一つ目の活用方法は、「堅牢なUI状態管理」である。最新のAndroidアプリケーション開発では、画面に表示されるUIは、その時々の「状態」によって決まるという考え方が主流だ。例えば、ニュース記事を表示する画面を想像してみよう。この画面は、「ニュースを読み込み中」「ニュースの読み込みに成功し、記事が表示されている」「ニュースの読み込みに失敗し、エラーメッセージが表示されている」といった、いくつかの異なる状態を取りうる。もし、これらの状態が適切に管理されていないと、「ローディングスピナーが表示されているのに、同時にエラーメッセージも表示されている」といった、矛盾した不可能なUI状態が生まれてしまう可能性がある。これはバグの温床となる。

この問題の解決策として、sealedインターフェースを使って、画面が取りうるすべての主要な状態を一つにまとめる方法がある。例えば、NewsUiStateというsealedインターフェースを定義し、その中にLoading（読み込み中を示すオブジェクト）、Success（記事のリストを含むデータクラス）、Error（エラーメッセージを含むデータクラス）といった具体的な状態を定義する。これにより、NewsUiState型の変数は、定義されたこれらのいずれかの状態にしかなることができないとコンパイラが保証してくれる。アプリケーションのビジネスロジックを担うViewModelという部分から、このNewsUiStateをStateFlowという仕組みでUIに公開する。UI側、例えばJetpack Composeで作られた画面の表示部分では、when式を使って現在のNewsUiStateがLoadingならローディングスピナーを、Successなら記事リストを、Errorならエラーメッセージを表示するといったように、それぞれの状態に応じたUIをレンダリングする。このwhen式は、sealedインターフェースのすべてのサブタイプを網羅しているかをコンパイラがチェックするため、開発者が状態の処理漏れを防ぐことができる。結果として、UIが矛盾した状態になることはコンパイル時に検出され、アプリケーションの堅牢性が大幅に向上する。

二つ目の活用方法は、「弾力的なエラーハンドリング」である。プログラムでエラーが発生した場合、通常は例外（Exception）を発生させて処理を中断するtry-catchブロックを用いることが多い。しかし、すべてのエラーが予期せぬ、アプリケーション全体を停止させるべき「例外」とは限らない。例えば、インターネット接続が一時的に失われたためにサーバーからデータを取得できなかった場合、これは予測可能な「失敗」であり、必ずしもプログラムをクラッシュさせる必要はない。このような予測可能な失敗に対して、try-catchを多用するとコードが読みにくくなることがある。

そこで、sealedインターフェースを使って、関数の結果として成功と失敗を明示的に表現する「Result型」を導入する方法が有効だ。Result<T>という汎用的なsealedインターフェースを定義し、その中にSuccess<T>（成功したデータTを含むデータクラス）とFailure（発生した例外情報Throwableを含むデータクラス）という二つのサブタイプを持たせる。データ層、例えばユーザー情報を取得するリポジトリの関数は、API呼び出しを行い、成功すればResult.Successを、ネットワークエラーなど予測可能な失敗が発生すればResult.Failureを返すように実装する。この際、try-catchは関数の内部に閉じ込められ、そのエラーを例外として再throwするのではなく、Result.Failureとして返却する。このようにすることで、この関数を呼び出す側（例えばViewModel）は、戻り値がResult<User>であることを知っており、when式を使ってSuccessの場合とFailureの場合の両方を必ず処理するようにコンパイラによって強制される。このパターンは、実行時に発生しがちなエラーをコンパイル時にチェックされる結果へと変換し、より予測可能で信頼性の高いアプリケーションロジックを構築することを可能にする。

しかし、sealedクラス/インターフェースの強力さゆえに、間違った使い方をしてしまう「アンチパターン」も存在する。その一つが、「イベントを状態として扱う」という罠である。例えば、ユーザーがあるボタンをクリックしたときに短いメッセージ（Toast）を表示したり、別の画面へ移動したりといった「一度きりのアクション」は、アプリケーションにおいて「イベント」と呼ばれる。これに対し、「状態」は永続的で、画面が現在「どうであるか」を示すものである。例えば、「ローディング中である」は状態だが、「Toastを表示する」はイベントである。

この罠とは、先ほどのUI状態を管理するsealed interface NewsUiStateに、object ShowToast : NewsUiStateのような形でイベントを追加してしまうことだ。これは一見すると便利に見えるが、問題を引き起こす。なぜなら、状態は永続的なので、画面が再描画されたり、デバイスの向きが変わったりすると、その状態が再度評価され、結果としてToastが何度も表示されてしまったり、意図しない画面遷移が繰り返されたりする可能性があるからだ。

この問題を避けるためには、永続的なUI状態と一度きりのイベントを明確に分離することが重要だ。UI状態は引き続きStateFlowを使ってsealed interfaceで管理する。一方、Toast表示や画面遷移のような一度きりのイベントは、SharedFlowやChannelといった別の仕組みを使ってViewModelからUIに通知する。ViewModelでユーザーが何らかのアクションを行った際に、Channelを通じてEvent.ShowToastのようなイベントを送信する。UI側では、Composable関数内でLaunchedEffectという仕組みを使い、ViewModelから送られてくるイベントを継続的に監視（収集）する。イベントが届いたときに、when式でそれがEvent.ShowToastであればToastを表示するといったように、一度きりの処理を実行する。この分離によって、UIの状態は予測可能なままでありながら、一度きりのアクションを確実かつ適切にトリガーできるようになる。

このように、Kotlinのsealedクラス/インターフェースを適切に活用することで、アプリケーション開発におけるUIの矛盾、エラー処理の煩雑さ、イベント管理の混乱といった一般的な課題を解決できる。これらのパターンを習得し実践することで、より安全で、理解しやすく、そして長期的に保守しやすい高品質なアプリケーションを構築することが可能となるだろう。