Javaポリモーフィズムとは？多態性の例とアップキャスト・ダウンキャスト

ポリモーフィズム（多態性）とは、同じメソッド呼び出しが、変数に入っているオブジェクトの種類によって違う動きをする仕組みです。 Javaでは「親の型の変数に子のインスタンスを入れる（アップキャスト）」と「子が親のメソッドを上書きする（オーバーライド）」の2つを組み合わせて使います。呼び出す側は a.cry() と1行書くだけで、実体が犬なら「ワンワン」、猫なら「ニャー」と動きが切り替わります。

この記事では、ポリモーフィズムを使わない版と使う版を並べて実行結果を比較し、アップキャスト・ダウンキャストの違い、ClassCastException が出る流れとスタックトレース、instanceof とパターンマッチングによる書き直しまでを順に確かめます。掲載したコードはすべて OpenJDK 21.0.10 で実行し、出力をそのまま載せています。ファイル名を合わせて java ファイル名.java で動かせます。

ポリモーフィズムの早見表

ポリモーフィズムを最小のコードで確かめる

まずは最小の例です。Animal を継承した Dog を作り、Animal 型の変数に入れて呼び出します。

// Basic.java
public class Basic {
    static class Animal {
        void cry() { System.out.println("（何かが鳴いた）"); }
    }
    static class Dog extends Animal {
        @Override void cry() { System.out.println("ワンワン"); }
        void fetch() { System.out.println("ボールを取ってきた"); }
    }

    public static void main(String[] args) {
        Animal a = new Dog();          // 変数の型はAnimal、実体はDog
        a.cry();                       // Dogのcry()が動く
        System.out.println(a.getClass().getSimpleName());
        System.out.println(a instanceof Animal);
        System.out.println(a instanceof Dog);
    }
}

実行結果（java Basic.java）:

ワンワン
Dog
true
true

変数の型は Animal ですが、動いたのは Dog の cry() です。どのメソッドが動くかは、変数の型ではなく実体の型で決まります。 この実行時の選択を「動的ディスパッチ（動的束縛）」と呼びます。

変数の型と実体の型を分けて考える

ポリモーフィズムを理解する近道は、1つの変数に「2つの型」があると捉えることです。

変数の型に無いメソッドは、実体が持っていても呼べません。上の a で a.fetch() と書くと、次のコンパイルエラーになります。

CompileErr.java:8: error: cannot find symbol
        a.fetch();
         ^
  symbol:   method fetch()
  location: variable a of type Animal
1 error
error: compilation failed

コンパイラは変数の型 Animal だけを見て判断するため、Animal に fetch() が無ければ受け付けません。fetch() を呼びたいときは、後で説明するダウンキャストを使います。

使わない版と使う版を実行結果で比べる

ポリモーフィズムの価値は、同じ処理を2通りに書くとはっきりします。3種類の動物を順に鳴かせるプログラムで比べます。

使わない版：型ごとに分岐する

共通の親を持たないクラスを Object の配列に入れ、型を調べて呼び分けます。

// NoPoly.java
public class NoPoly {
    static class Dog { void bark() { System.out.println("ワンワン"); } }
    static class Cat { void meow() { System.out.println("ニャー"); } }
    static class Bird { void sing() { System.out.println("ピヨピヨ"); } }

    public static void main(String[] args) {
        Object[] animals = { new Dog(), new Cat(), new Bird() };
        for (Object a : animals) {
            // 型ごとに分岐し、型ごとに別のメソッドを呼ぶ
            if (a instanceof Dog) {
                ((Dog) a).bark();
            } else if (a instanceof Cat) {
                ((Cat) a).meow();
            } else if (a instanceof Bird) {
                ((Bird) a).sing();
            }
        }
    }
}

実行結果:

ワンワン
ニャー
ピヨピヨ

使う版：呼び出しは1行になる

共通の親 Animal に cry() を用意し、各クラスがオーバーライドします。

// WithPoly.java
public class WithPoly {
    static abstract class Animal {
        abstract void cry();   // 鳴き方はサブクラスが決める
    }
    static class Dog extends Animal {
        @Override void cry() { System.out.println("ワンワン"); }
    }
    static class Cat extends Animal {
        @Override void cry() { System.out.println("ニャー"); }
    }
    static class Bird extends Animal {
        @Override void cry() { System.out.println("ピヨピヨ"); }
    }

    public static void main(String[] args) {
        Animal[] animals = { new Dog(), new Cat(), new Bird() };
        for (Animal a : animals) {
            a.cry();   // 呼び出しは1行。動きは実体の型で決まる
        }
    }
}

実行結果:

ワンワン
ニャー
ピヨピヨ

出力はまったく同じです。違いは、呼び出す側のコードの形に表れます。

2つの版の違いを表で見る

種類が増えても呼び出し側を直さずに済むことが、ポリモーフィズムのいちばんの利点です。「新しい種類を足すときに、既存のコードを書き換える箇所が少ない」設計になります。

クラスの関係を図で確認する

classDiagram
    class Animal {
        <<abstract>>
        +cry()
    }
    class Dog {
        +cry()
        +fetch()
    }
    class Cat {
        +cry()
        +scratch()
    }
    Animal <|-- Dog
    Animal <|-- Cat

矢印の先（Animal）が親、根元（Dog Cat）が子です。子から親の方向へ型を変えるのがアップキャスト、親から子の方向がダウンキャストです。

アップキャストとダウンキャストの違い

違いをまとめた比較表

どちらのキャストもオブジェクト自体は変化しません。変わるのは「どの型の窓からそのオブジェクトを見るか」だけです。アップキャストすると窓が狭くなり、ダウンキャストすると元の広さに戻る、と考えると整理しやすくなります。

アップキャストが起きる4つの場面

アップキャストは代入のときだけでなく、いろいろな場面で自動的に行われています。

ダウンキャストでClassCastExceptionを再現する

ダウンキャストは、実体が指定した型（またはその子）であるときだけ成功します。成功する場合と、例外になる場合を続けて実行します。

// CastDemo.java
public class CastDemo {
    static class Animal { void cry() { System.out.println("（何かが鳴いた）"); } }
    static class Dog extends Animal {
        @Override void cry() { System.out.println("ワンワン"); }
        void fetch() { System.out.println("ボールを取ってきた"); }
    }
    static class Cat extends Animal {
        @Override void cry() { System.out.println("ニャー"); }
        void scratch() { System.out.println("爪をといだ"); }
    }

    public static void main(String[] args) {
        Animal a = new Dog();   // アップキャスト（キャストの記述は不要）
        Dog d = (Dog) a;        // ダウンキャスト（実体がDogなので成功）
        d.fetch();

        Animal b = new Cat();
        Dog e = (Dog) b;        // 実体はCat。コンパイルは通るが実行時に例外
        e.fetch();
    }
}

実行結果（javac CastDemo.java のあと java CastDemo）:

ボールを取ってきた
Exception in thread "main" java.lang.ClassCastException: class CastDemo$Cat cannot be cast to class CastDemo$Dog (CastDemo$Cat and CastDemo$Dog are in unnamed module of loader 'app')
    at CastDemo.main(CastDemo.java:18)

1つ目のダウンキャストは成功し、2つ目で ClassCastException が発生しました。コンパイルは通るのに実行時に止まる点が、ダウンキャストで気をつけたいところです。

スタックトレースの読み方

メッセージの「A cannot be cast to B」を「実体はA、変換しようとした型はB」と読むと、原因がすぐ分かります。なお java CastDemo.java のようにソースファイルを直接実行した場合、括弧内のローダー名は com.sun.tools.javac.launcher.Main$MemoryClassLoader @19dc67c2 のような表示になりました（例外の種類と行番号は同じです）。

継承関係がない型へのキャストはコンパイルエラーになる

Dog と String のように親子関係がまったくないクラス同士では、キャストを書いた時点でコンパイラが「変換できない型」として知らせてくれます（この1点は今回未実行で、Java言語の一般に知られた仕様としての説明です）。実行時の例外になるのは、コンパイラから見て「成立する可能性がある」キャストです。Animal 型の変数の中身は Dog かもしれないし Cat かもしれないので、コンパイラは (Dog) b を通します。

instanceofとパターンマッチングで安全に書き直す

ClassCastException を避ける基本は、キャストの前に instanceof で実体の型を確かめることです。Javaのバージョンによって3通りの書き方があります。

// SafeCast.java
import java.util.List;

public class SafeCast {
    static class Animal { void cry() { System.out.println("（何かが鳴いた）"); } }
    static class Dog extends Animal {
        @Override void cry() { System.out.println("ワンワン"); }
        void fetch() { System.out.println("ボールを取ってきた"); }
    }
    static class Cat extends Animal {
        @Override void cry() { System.out.println("ニャー"); }
        void scratch() { System.out.println("爪をといだ"); }
    }

    public static void main(String[] args) {
        List<Animal> animals = List.of(new Dog(), new Cat());

        System.out.println("--- 1. instanceof + キャスト（どのバージョンでも書ける）");
        for (Animal a : animals) {
            if (a instanceof Dog) {
                Dog d = (Dog) a;
                d.fetch();
            } else if (a instanceof Cat) {
                Cat c = (Cat) a;
                c.scratch();
            }
        }

        System.out.println("--- 2. instanceofのパターンマッチング（Java 16以降）");
        for (Animal a : animals) {
            if (a instanceof Dog d) {
                d.fetch();
            } else if (a instanceof Cat c) {
                c.scratch();
            }
        }

        System.out.println("--- 3. switchのパターンマッチング（Java 21以降）");
        for (Animal a : animals) {
            switch (a) {
                case Dog d -> d.fetch();
                case Cat c -> c.scratch();
                default -> a.cry();
            }
        }

        System.out.println("--- 4. nullはinstanceofでfalseになる");
        Animal n = null;
        System.out.println(n instanceof Dog);
    }
}

実行結果:

--- 1. instanceof + キャスト（どのバージョンでも書ける）
ボールを取ってきた
爪をといだ
--- 2. instanceofのパターンマッチング（Java 16以降）
ボールを取ってきた
爪をといだ
--- 3. switchのパターンマッチング（Java 21以降）
ボールを取ってきた
爪をといだ
--- 4. nullはinstanceofでfalseになる
false

3つの書き方の比較表

パターンマッチングでは、判定と変数への代入が同時に行われるため、型名の書き間違いによる ClassCastException が起きる余地がなくなります。また、null に対する instanceof は常に false になるので、nullチェックを別に書かなくても if の中には入りません。

sealedと組み合わせて網羅を確認する

Java 17以降の sealed（継承できる型を限定する機能）と組み合わせると、switch で全種類を扱えているかをコンパイラが確認してくれます。

// Sealed.java
public class Sealed {
    sealed interface Shape permits Circle, Rect {}
    record Circle(double r) implements Shape {}
    record Rect(double w, double h) implements Shape {}

    static double area(Shape s) {
        return switch (s) {          // defaultなしで全種類を網羅できる
            case Circle c -> Math.PI * c.r() * c.r();
            case Rect r -> r.w() * r.h();
        };
    }
    public static void main(String[] args) {
        System.out.printf("%.2f%n", area(new Circle(1)));
        System.out.printf("%.2f%n", area(new Rect(2, 3)));
    }
}

実行結果:

3.14
6.00

ダウンキャストが必要になったら設計を見直す合図

ダウンキャストや型判定が何度も出てくるときは、その処理を親の型のメソッドとして定義し、各クラスでオーバーライドできないかを考えてみると、コードがすっきりすることが多くあります。

多態にならないもの：フィールド・static・private

「実体の型で決まる」のは、オーバーライドしたインスタンスメソッドだけです。フィールド、staticメソッド、privateメソッドは変数の型（または定義したクラス）で決まります。1つのプログラムでまとめて確かめます。

// FieldStatic.java
public class FieldStatic {
    static class Parent {
        String name = "Parentのフィールド";
        static void hello() { System.out.println("Parent.hello()"); }
        void show() { System.out.println("Parent.show()"); }
        private void secret() { System.out.println("Parent.secret()"); }
        void callSecret() { secret(); }
    }
    static class Child extends Parent {
        String name = "Childのフィールド";                              // フィールドの隠蔽
        static void hello() { System.out.println("Child.hello()"); }    // staticメソッドの隠蔽
        @Override void show() { System.out.println("Child.show()"); }   // オーバーライド
        void secret() { System.out.println("Child.secret()"); }         // 別メソッド扱い
    }

    public static void main(String[] args) {
        Parent p = new Child();
        p.show();                               // インスタンスメソッド → 実体の型
        System.out.println(p.name);             // フィールド → 変数の型
        p.hello();                              // staticメソッド → 変数の型
        p.callSecret();                         // privateメソッド → 定義したクラス
        System.out.println(((Child) p).name);   // ダウンキャストすればChild側が見える
    }
}

実行結果:

Child.show()
Parentのフィールド
Parent.hello()
Parent.secret()
Childのフィールド

何が実体の型で決まるかの一覧

この結果から、次の3つの書き方がおすすめです。

• フィールドは private にして、値の取得はメソッド（getter）経由にする。メソッドなら多態が働きます。
• staticメソッドは Parent.hello() のようにクラス名で呼ぶ。変数経由で呼ぶと、どちらが動くかが読み手に伝わりにくくなります。
• 親と同じ名前のフィールドを子で定義しない。必要な値は親のフィールドを使うか、別の名前にします。

@Overrideで上書きの書き間違いを見つける

メソッド名や引数の型が少しでも違うと、オーバーライドではなく「別のメソッドの追加」になり、多態が働きません。@Override を付けておくと、親に同じシグネチャ（メソッド名と引数の並び）のメソッドが無い場合にコンパイラが知らせてくれます。オーバーライドするメソッドには必ず @Override を付ける習慣にすると安心です。

オーバーライドが成立する主な条件は次のとおりです（Java言語仕様の一般的な規則です）。

オーバーライドとオーバーロードの違い

名前が似ている2つですが、メソッドが選ばれるタイミングが違います。オーバーロード（同じ名前で引数が違うメソッドを複数定義すること）は、コンパイル時に変数の型で選ばれます。

// Overload.java
public class Overload {
    static class Animal {}
    static class Dog extends Animal {}

    static void greet(Animal a) { System.out.println("greet(Animal)"); }
    static void greet(Dog d)    { System.out.println("greet(Dog)"); }

    public static void main(String[] args) {
        Animal a = new Dog();
        Dog d = new Dog();
        greet(a);        // 変数の型Animalで決まる
        greet(d);        // 変数の型Dogで決まる
        greet((Dog) a);  // キャストすると変数側の型がDogになる
    }
}

実行結果:

greet(Animal)
greet(Dog)
greet(Dog)

1行目に注目してください。a の実体は Dog ですが、呼ばれたのは greet(Animal) です。引数として渡したオブジェクトの実体の型は、オーバーロードの選択には使われません。

引数の実体の型に応じて処理を変えたいときは、オーバーロードではなく、引数のオブジェクト自身にメソッドを持たせてオーバーライドするか、switch のパターンマッチングで振り分けます。

インタフェースでポリモーフィズムを使う

継承（extends）だけでなく、インタフェースの実装（implements）でも同じように多態が働きます。通知の送り先を入れ替える例です。

// Iface.java
import java.util.List;

public class Iface {
    interface Notifier {
        void send(String message);
        default void sendAll(List<String> messages) {   // defaultメソッドも多態に参加する
            for (String m : messages) send(m);
        }
    }
    static class MailNotifier implements Notifier {
        @Override public void send(String message) { System.out.println("[メール] " + message); }
    }
    static class ChatNotifier implements Notifier {
        @Override public void send(String message) { System.out.println("[チャット] " + message); }
    }

    // 引数の型をインタフェースにすると、渡す実体を入れ替えられる
    static void notifyStock(Notifier notifier) {
        notifier.send("在庫が残り3個です");
    }

    public static void main(String[] args) {
        notifyStock(new MailNotifier());
        notifyStock(new ChatNotifier());
        notifyStock(m -> System.out.println("[ラムダ] " + m));   // ラムダ式も実体になれる
        new ChatNotifier().sendAll(List.of("A", "B"));
    }
}

実行結果:

[メール] 在庫が残り3個です
[チャット] 在庫が残り3個です
[ラムダ] 在庫が残り3個です
[チャット] A
[チャット] B

notifyStock は Notifier という型しか知りません。それでも、渡す実体を変えるだけで送り先が切り替わります。抽象メソッドが1つだけのインタフェースなら、ラムダ式も実体として渡せます。default メソッドの sendAll の中で呼ばれる send も、実体（ChatNotifier）のものが選ばれています。

標準ライブラリで使われている例

ふだん書いているコードにも、ポリモーフィズムはたくさん登場しています。

println(obj) が toString() の内容を表示するのも、Object 型で受け取って実体の toString() を呼ぶ、というポリモーフィズムの働きです。

継承・抽象クラス・インタフェースの使い分け早見表

ポリモーフィズムを使う土台は3種類あります。どれを選ぶかの目安を表にまとめます。

選び方の目安

迷ったときは、まずインタフェースで型を決め、共通処理が増えてきたら抽象クラスを間に挟む、という順で考えると無理のない構成になります。

つまずきやすいポイントと書き方のコツ

コンストラクタからオーバーライドされるメソッドを呼ぶとnullが見える

コンストラクタの中でも動的ディスパッチは働きます。そのため、親のコンストラクタが呼んだメソッドが子でオーバーライドされていると、子のフィールドが初期化される前に子のメソッドが動きます。

// CtorTrap.java
public class CtorTrap {
    static class Base {
        Base() { init(); }                 // コンストラクタからオーバーライド可能なメソッドを呼ぶ
        void init() { System.out.println("Base.init()"); }
    }
    static class Sub extends Base {
        private String label = "準備完了";
        @Override void init() { System.out.println("Sub.init() label=" + label); }
    }
    public static void main(String[] args) {
        new Sub();
    }
}

実行結果:

Sub.init() label=null

label には「準備完了」を代入しているのに、表示は null です。親のコンストラクタ → 子のフィールド初期化、の順で処理が進むためです。コンストラクタから呼ぶメソッドは private か final にすると、この順序の影響を受けなくなります。

配列のアップキャストは実行時に型が確認される

配列も Object[] objs = new String[2]; のようにアップキャストできます。ただし実体は String[] のままなので、別の型の要素を入れると実行時に ArrayStoreException になります。

Exception in thread "main" java.lang.ArrayStoreException: java.lang.Integer
    at ArrayStore.main(ArrayStore.java:5)

（objs[1] = Integer.valueOf(1); を実行したときの出力です。）

ジェネリクスのListは要素の親子関係を引き継がない

Dog は Animal の子ですが、List<Dog> は List<Animal> の子ではありません。代入するとコンパイルエラーになります。

Generic.java:7: error: incompatible types: List<Dog> cannot be converted to List<Animal>
        List<Animal> animals = dogs;
                               ^
1 error
error: compilation failed

読み取り専用で受け取りたいときは、引数の型を List<? extends Animal> にすると、List<Dog> も List<Cat> も渡せるようになります。

よく見るエラーと対処の一覧

書くときのチェックリスト

よくある質問

Q. ポリモーフィズムと継承は何が違いますか？ A. 継承は「親のフィールドやメソッドを子が引き継ぐ仕組み」、ポリモーフィズムは「同じ呼び出しで実体ごとに動きが変わる性質」です。継承（またはインタフェースの実装）とオーバーライドがあって、はじめてポリモーフィズムが成り立ちます。継承は土台、ポリモーフィズムはその土台の活かし方、という関係です。

Q. アップキャストするとサブクラスの情報は消えますか？ A. 消えません。オブジェクトは new したときの型のままで、変数の型という「見え方」だけが変わります。そのため a.getClass() は実体の型を返し、ダウンキャストすれば子に固有のメソッドを再び呼べます。

Q. ダウンキャストはなるべく使わないほうがよいですか？ A. 必要な場面はあります。子に固有の機能を使うときや、equals の実装で相手の型を確かめるときなどです。使うときは instanceof のパターンマッチングと組み合わせると安全に書けます。種類ごとの分岐が何度も出てくる場合は、親にメソッドを定義してオーバーライドする形にできないかを検討するとよいでしょう。

Q. 抽象クラスやインタフェースが無くてもポリモーフィズムは使えますか？ A. 使えます。通常のクラスを継承してメソッドをオーバーライドすれば多態が働きます（この記事の最初の例がそうです）。抽象クラスやインタフェースを使うと、「子が必ず実装する」ことをコンパイラが確認してくれるため、実装漏れに早く気づけます。

まとめ

• ポリモーフィズムは、同じ呼び出しが実体の型に応じて違う動きをする仕組み。継承または実装、オーバーライド、親の型の変数の3つがそろうと働く
• 呼べるメソッドは変数の型で、動くメソッドは実体の型で決まる
• アップキャストは自動で常に成功、ダウンキャストは記述が必要で実行時に確認される
• 実体が合わないダウンキャストは ClassCastException。メッセージは「実体の型 cannot be cast to 変換先の型」と読む
• instanceof Dog d（Java 16以降）や switch のパターン（Java 21以降） を使うと、判定とキャストを1つにまとめられる
• フィールド・staticメソッド・privateメソッド・オーバーロードの選択は多態にならない
• 迷ったら インタフェースで型を決め、共通処理が増えたら抽象クラス を検討する

株式会社RJCでは、Javaのポリモーフィズムやオブジェクト指向の考え方を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。