導入: なぜ Sealed Classes と網羅性チェックが重要なのか
実務におけるJava開発では、特定のビジネスロジックを表現するために「状態」や「型」を制限したい場面が多くあります。従来のJavaでは、enum以外の型で網羅性を担保するのが難しく、if-elseの連鎖や、switch文のdefault節に頼ることで「意図しない型の混入」を見逃してしまうリスクがありました。Java 17で導入されたSealed Classes（封印クラス）と、それに付随するswitch式の網羅性チェックを活用することで、コンパイル時に「全てのケースを考慮したか」を強制し、バグを未然に防ぐ堅牢なコードを実現できます。
基礎知識: Sealed Classes と Switch Expressions
Sealed Classes は、継承できるクラスやインターフェースを特定のサブクラスに限定する機能です。これにより、階層が閉じていることが保証されます。
Switch Expressions (switch式) は、Java 14以降で導入された形式で、文（Statement）ではなく値（Expression）を返します。これに 網羅性チェック (Exhaustiveness check) が加わることで、もしSealed Classesのサブクラスが追加された際、switch式で対応漏れがあればコンパイルエラーとして検知できるようになりました。
実装/解決策: 網羅性を活かした設計
実装のポイントは、Sealed Classesで型階層を定義し、switch式でサブクラスを一つずつ処理することです。もし処理を忘れた場合、コンパイラが「網羅性が不完全である」と警告・エラーを出してくれます。これにより、将来的な機能拡張時にも、修正漏れを防ぐ強力なセーフティネットとして機能します。
サンプルプログラム: Sealed Classes を活用した決済処理
以下のコードは、決済の状態をSealed Interfaceで定義し、switch式で処理を分岐させる実用的な例です。
// 決済状態を定義（許可されたサブクラスのみが実装可能）
sealed interface PaymentStatus permits Pending, Success, Failed {}
record Pending(String orderId) implements PaymentStatus {}
record Success(String transactionId) implements PaymentStatus {}
record Failed(String reason) implements PaymentStatus {}
public class PaymentProcessor {
public String handlePayment(PaymentStatus status) {
// switch式による網羅的な処理
// もし新しいStatusが追加された場合、ここがコンパイルエラーになるため修正漏れを防げる
return switch (status) {
case Pending p -> "注文 " + p.orderId() + " は処理中です。";
case Success s -> "決済完了: ID " + s.transactionId();
case Failed f -> "決済失敗: 理由 " + f.reason();
// default節をあえて書かないことで、網羅性をコンパイラにチェックさせるのがコツ
};
}
}
応用・注意点: 現場で役立つTips
1. default節を避ける: 網羅性を最大限に活用するためには、可能な限りswitch式でdefault節を記述しないようにしてください。default節を書くと、新しいサブクラスを追加した際にコンパイラが警告を出せなくなります。
2. レコードクラスとの併用: データ保持が主目的であれば、Sealed Classesとrecordを組み合わせるのが最適です。不変性と型安全性が両立され、コードが非常に簡潔になります。
3. ライブラリのバージョン: この機能はJava 17以降で正式導入されています。既存のプロジェクトで利用する場合は、ビルドツールの設定（Maven/Gradle）でターゲットバージョンが正しく設定されているか確認してください。
この手法を取り入れることで、複雑な条件分岐のメンテナンス性が飛躍的に向上します。ぜひ次回の機能追加の際に試してみてください。
コメント