Javaのsealedクラスに関して、switch文で分岐して処理をした際にわからないことがあったので質問いたします。

Question

実現したいこと

『すっきりわかるJava実践編』という書籍にて勉強していたところシールクラスについて記載があり、自分でも試しながら作成していたところ、switch文で子クラスのインスタンスが渡された際の処理を分岐している記述で「defalt句」を使用せずに実現できる方法について記載のあった以下のコードで疑問がありました。

public sealed class Charactor permits Hero,Wizard{}
public final class Hero extends Charactor{}
public final class Wizard extends Charactor{}

上記継承関係のクラスを作成し

public void heal(Charactor target){
switch(target){
  case Hero h ->{h.hp += 20;}
  case Wizard w -> {w.hp += 5;}
}
}

というメソッドを作成し分岐させることができ、かつ子クラスはpermitsで指定しているHeroとWizardに限定されるため、default句を使用しなくてもコンパイルエラーは発生しないということだったのですが、自分で試してやってみたところ、コンパイルエラーが発生しました。

発生している問題・分からないこと

コンパイルエラーの原因はswitch文がすべての可能な入力値をカバーしていないというものでしたが、default句もしくは親クラスであるCharactorのインスタンスが渡された際の処理を記述したところエラーは解消しました。
そこで疑問だったのが、書籍では、継承された子クラスのみの分岐処理を記載しシールクラスの有用性を説明しており、便利な機能だなと自分もそれで納得していたのですが、親クラスのインスタンスを渡した際の処理を書かなければならないならば、書籍もそういう記載にしていたはずだと感じまして、自分で勝手に作ったクラス、もしくはhealメソッドの記載場所等にに何か誤りがあるかといろいろやってみたのですが、コンパイルは一向に通らず、このケースではやはり親クラスのインスタンスを渡した際の処理の記述の必要があるのでしょうか。また、子クラスのインスタンスが渡ってきた際の処理の記述のみでOKな方法はあるのでしょうか。
ご教示しただけますと幸いです。
よろしくお願いいたします。

エラーメッセージ

Main.java:20: エラー: switch文がすべての可能な入力値をカバーしていません

該当のソースコード

特になし

試したこと・調べたこと

• teratailやGoogle等で検索した
• ソースコードを自分なりに変更した
• 知人に聞いた
• その他

上記の詳細・結果

    public static void main(String[] args) {
        Animal dog = new Dog(10,"Dog");
        Animal cat = new Cat(10,"Cat");
        Bird bird = new Bird(10,"Bird");
        Animal animal = new Animal();

        cat.heal(cat);
        System.out.println(cat);
        animal.heal(animal);
        // bird.heal(bird);
        // System.out.println(bird);
        
    }
    
}

sealed class Animal permits Dog,Cat{
    public void heal(Animal target){
        switch (target) {
            case Dog d->{d.hp += 20;}
            case Cat c->{c.hp += 100;}
            //case Animal a ->{System.out.println("too bad");}
        }
    }
    
}

final class Dog extends Animal{
    int hp;
    String name;
    public Dog(int hp,String name){
        this.hp = hp;
        this.name = name;
    }
    @Override
    public String toString(){
        return this.name+":"+this.hp;
    }
}
final class Cat extends Animal{
    int hp;
    String name;
    public Cat(int hp,String name){
        this.hp = hp;
        this.name = name;
    }
    @Override
    public String toString(){
        return this.name+":"+this.hp;
    }
}
// Animalにpremitsされていないため、Animal継承不可
final class Bird{
    int hp;
    String name;
    public Bird(int hp,String name){
        this.hp = hp;
        this.name = name;
    }
    
    @Override
    public String toString(){
        return this.name+":"+this.hp;
    }
}

補足

特になし

Comments

[jimbe]

「エラーメッセージ」の出た時のコードを「該当のソースコード」に載せて頂けますか。

また、コンパイルに使った java のバージョン等もあると良いかもしれません。(特定のバージョンでバグがあったとかの可能性とか)

[1121]

「エラーメッセージ」
Main.java:20: エラー: switch文がすべての可能な入力値をカバーしていません
とご記載があります。
> コンパイルエラーの原因はswitch文がすべての可能な入力値をカバーしていないというものでしたが、default句もしくは親クラスであるCharactorのインスタンスが渡された際の処理を記述したところエラーは解消しました。
と、エラーメッセージの内容を解消しているようですが
> コンパイルは一向に通らず
とあり修正したソースコードとエラーメッセージは何になるのか私には読み取れませんでした
paiza cloud で試してみたのですが違いをおしえてもらえないでしょうか
https://paiza.io/projects/6xaB6e7w6XAqyYWJepfYgA
※書き換えてもらって大丈夫です。構文エラーが出る状態が望ましいです。細かい制限はあります。。。

[退会済みユーザー]

あんまりちゃんと読んだり検証してないのでコメントで。

JDK21で入ったPattern Matching for switch Expressions and Statementsは以下のとおりです。
https://docs.oracle.com/en/java/javase/21/language/pattern-matching-switch-expressions-and-statements.html

ここで参照される
https://openjdk.org/jeps/441

にある以下の記述がその理由かと思います。ようはコンパイルした後で変わる可能性があるからです。

Again, the notion of exhaustiveness is an approximation. Because of separate compilation, it is possible for a novel implementation of the interface I to show up at runtime, so the compiler will in this case insert a synthetic default clause that throws.

実際複数ファイルに分けてインスタンス生成も分けてビルドすると、switch文を含むjavaファイルをコンパイルせずにsealed classを変更して、その新しいクラスのインスタンスを生成して渡せます。単純にはnullを渡すだけでも必要になりますね。抽象クラスやinterfaceでは違うチェックになるようで、defaultは不要になり、同じ操作をすると実行時例外になります。

[退会済みユーザー]

一応Unix系用ですが検証用コードを載せておきます。
cat >Main.java <<EOF
public class Main {
private static void hoge(Charactor target) {
switch(target){
case Hero h ->{System.out.println("Hero");}
case Wizard w -> {System.out.println("Wizard");}
//case null -> {System.out.println("null");}
default ->{System.out.println("default");}
}
}
public static void main(String[] args) {
hoge(new Factory().create());
}
}
EOF
cat >Charactor.java <<EOF
public sealed class Charactor permits Hero,Wizard{}
//public abstract sealed class Charactor permits Hero,Wizard{}
//public sealed class Charactor permits Hero,Wizard,Warrior{}
//public abstract sealed class Charactor permits Hero,Wizard,Warrior{}
EOF
cat >Hero.java <<EOF
public final class Hero extends Charactor{}
EOF
cat >Wizard.java <<EOF
public final class Wizard extends Charactor{}
EOF
cat >Warrior.java <<EOF
public final class Warrior extends Charactor{}
EOF
cat >Factory.java <<EOF
public class Factory {
public Charactor create() {return new Hero();}
//public Charactor create() {return new Warrior();}
}
EOF
javac Main.java
java Main
ls -lAFrt
cat >Charactor.java <<EOF
//public sealed class Charactor permits Hero,Wizard{}
//public abstract sealed class Charactor permits Hero,Wizard{}
public sealed class Charactor permits Hero,Wizard,Warrior{}
//public abstract sealed class Charactor permits Hero,Wizard,Warrior{}
EOF
cat >Factory.java <<EOF
public class Factory {
//public Charactor create() {return new Hero();}
public Charactor create() {return new Warrior();}
}
EOF
javac Factory.java
java Main
ls -lAFrt

[退会済みユーザー]

色々書きましたが、「コンパイルした後で変わる可能性があるから」というよりは、単純に「(インスタンス化可能な)型を網羅していないから」の方がエラーの整合が取れますね。私の言った理由はdefault分岐コードを書いたら分岐がなさそうでもコード生成される理由と言った方が近いようです。
なお書籍の掲載コードをダウンロードしましたが、sealedを使った記述は見つからず、code15-06に

> // Characterクラス。
> // 未来の開発者はこれを継承してHeroやWizardを作る。
> public abstract class Character {

という記述が見つかっただけでした。何やら分かりませんが、そもそもabstractっぽい感じですね。

[kaguyabito]

Unix系はまだ勉強しておらず、ご記載いただいたコードも私には理解が及びそうもありませんが
ご検証頂いた結果、書籍ではabstractへの言及をしていなかったため、勝手に混乱していたみたいでした。
自分が抜けていたnullへの分岐もご記載頂きありがとうございます。
不勉強で申し訳ございませんが、コメントありがとうございました！

[kaguyabito]

すみません！
コメントが折りたたまれていたことに気づかず、全てのコメントを今確認いたしました。jimbe様、1121様もご検討いただきありがとうございました！
回答にあったnanashi123様をベストアンサーにいたしましたがご要望など色々修正できず申し訳ございませんでした。

[退会済みユーザー]

多重継承(Javaはそもそもできない)や実装の継承を嫌う昨今、abstractクラスはそんなに使われないので、多いのは継承構造をガチガチにしないinterfaceだと思いますよ。私もそうですが、回答の方でもextends→implementsが面倒だったのでabstractを使っただけだと思います。

Answer 1

入力値というのは、引数に渡されうる全ての値を指すので、その全てのパターンに対応する必要があります
Charactorは子クラスを含むだけでなく、単体でのインスタンス化も可能です
またインスタンスにはnullが想定されるため、これの対応も必要になると思われますが、これは除外しても問題なく、こちらの方が仕様としては不可解な気はします

ともあれ、対策としてはCharactorが絶対にインスタンス化されない環境を用意すればいいことになります
Javaにおいて基底型単体のインスタンス生成を禁止する修飾子がabstractです

sealed abstract class Charactor permits Hero,Wizard{
　　protected int hp=0;

　　public static void heal(Charactor target)
　　　　switch(target){
　　　　　　case Hero h ->{h.hp += 20;}
　　　　　　case Wizard w -> {w.hp += 5;}
　　　　}
　　}
}

これでCharactorだけが渡るケースを除外することができます
参考書ではおそらくこのパターンを見落としているのでしょう

defaultは全ての例外パターンに対応するブロックです
例外の余地が一切認められない場合には、これを省略することができます
しかし例外を排除することは難しく、例えば

sealed class Charactor permits Hero,Wizard{
　　protected Charactor(){}
}

などの一見外部からインスタンス生成することが不可能に思える設計であっても、メソッドの戻り値で単体のインスタンスを補足できてしまう可能性があるので、このケースを除外できません
sealedでパターンを絞れるのは継承先を限定できるからであって、この修飾子特有の恩恵というわけではありません
最も、その設計が難しいのでそれを簡易化する修飾子が提供されています

Comments

[kaguyabito]

ご回答ありがとうございます。
そもそも、親クラスのインスタンスをabstractで生成できないようにするんですね！
しかし、例外がある旨もご教示いただきありがとうございます。
使用するケースがあれば慎重に検討いたします。
ベストアンサーとさせていただきました。
ありがとうございます！