Javaのポリモーフィズム：1つのインターフェース、多くの形

1つの参照、多くの型

ポリモーフィズムは継承とインターフェースの成果です。親（またはインターフェース）として型付けされた1つの変数が、任意のサブタイプのオブジェクトを保持でき、その上でメソッドを呼ぶと、Javaは変数の宣言された型が示すバージョンではなく、オブジェクトの実際のクラスに属するバージョンを実行することを意味します。

継承のページですでに下地は見たはずです。サブクラスが親のメソッドをオーバーライドする、というものです。ポリモーフィズムこそが、そのオーバーライドを価値あるものにします。一般的な型に対してコードを書き、それぞれの具体的なオブジェクトに独自の振る舞いをさせることができるのです。

class Animal {
    String speak() { return "..."; }
}

class Dog extends Animal {
    String speak() { return "Woof"; }
}

class Cat extends Animal {
    String speak() { return "Meow"; }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // 子オブジェクトを保持する親参照
        Animal b = new Cat();

        System.out.println(a.speak());   // Woof
        System.out.println(b.speak());   // Meow
    }
}

a も b も Animal として宣言されていますが、それぞれが自分の音を出力します。この選択は実際のオブジェクトに基づいて実行時に行われます。

動的メソッドディスパッチ

この背後にある仕組みが 動的メソッドディスパッチ（dynamic method dispatch）です。オーバーライドされたインスタンスメソッドについて、JVMはどの実装を呼び出すかを決めるためにオブジェクトの実行時クラスを見ます。コンパイラはメソッドが宣言された型に存在することだけを確認し、実際の選択はプログラムが実行されるまで先送りされます。

これこそが、1つのループがそれぞれが何であるかを一切尋ねることなく、あらゆる型の混在を扱えるようにするものです。

import java.util.List;

class Shape {
    double area() { return 0; }
}

class Circle extends Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    double area() { return Math.PI * r * r; }
}

class Square extends Shape {
    private final double side;
    Square(double side) { this.side = side; }
    double area() { return side * side; }
}

public class Main {
    public static void main(String[] args) {
        List<Shape> shapes = List.of(new Circle(1), new Square(2), new Circle(3));

        double total = 0;
        for (Shape shape : shapes) {
            total += shape.area();   // 各呼び出しは実際のサブクラスにディスパッチされる
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

ループは Shape しか知りません。後で Triangle extends Shape を追加しても、このコードは変更なしで動き続けます。それがまさに狙いです。コードは具体的な型の一覧ではなく、抽象に依存しているのです。

アップキャストとダウンキャスト

Dog を Animal 変数に格納するのは アップキャスト です。階層を上って、より一般的な型へ移動します。これは常に安全で、すべての Dog は Animal である（is a）ため、Javaは暗黙的に行います。

逆方向へ進むのが ダウンキャスト です。親参照を取り、それを特定のサブタイプとして扱います。これはオブジェクトが本当にそのサブタイプである場合にのみ有効なので、キャストを明示的に書く必要があり、間違えると ClassCastException のリスクを負います。

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal { }

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // アップキャスト - 暗黙的、安全

        Dog d = (Dog) a;        // ダウンキャスト - 明示的、a は本当に Dog なので有効
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // コンパイルは通るが、実行時に ClassCastException をスローする
        wrong.fetch();
    }
}

最後のキャストは問題なくコンパイルされます。コンパイラはそれが誤りだと証明できないからです。しかし Cat は Dog ではないため、実行すると破綻します。当てずっぽうでダウンキャストしてはいけません。

instanceofでダウンキャストをガードする

ダウンキャストの前に、instanceof で実際の型を確認しましょう。現代のJavaでは結果を同じ式の中でバインドでき（instanceof のパターンマッチング）、別途のキャストを省けます。

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal {
    void scratch() { System.out.println("scratching"); }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Dog(), new Cat(), new Dog() };

        for (Animal animal : animals) {
            if (animal instanceof Dog dog) {     // 型を確認し、かつ dog にバインドする
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof は null に対して false を返すため、このチェックは NullPointerException からも守ってくれます。とはいえ、長い instanceof の連鎖を書いていることに気づいたら、それはその振る舞いがオーバーライドされたメソッドとしてクラスの内側に属すべきサインであることが多いです。分岐はポリモーフィズムに任せましょう。

overriding と overloading

この2つは似て聞こえますが無関係であり、混同するのは典型的な混乱の原因です。

オーバーライド（overriding） は、サブクラスが親のメソッドを同一のシグネチャで置き換えることです。オブジェクトの型によって実行時に解決されます。これが私たちが使ってきたポリモーフィズムです。

オーバーロード（overloading） は、1つのクラスが同じ名前でパラメータリストの異なる複数のメソッドを持つことです。引数の型によってコンパイル時に解決され、実行時のディスパッチは一切関与しません。

public class Main {
    static String describe(int x)    { return "int: " + x; }
    static String describe(double x) { return "double: " + x; }
    static String describe(String x) { return "String: " + x; }

    public static void main(String[] args) {
        System.out.println(describe(5));      // int: 5
        System.out.println(describe(5.0));    // double: 5.0
        System.out.println(describe("five")); // String: five
    }
}

コンパイラは引数の静的型だけから、一致する describe を選びます。親子のオブジェクトは一切関与しないため、これは実行時ポリモーフィズムではありません。単にメソッド名を再利用しているだけです。

よくある落とし穴：フィールドはポリモーフィックではない

実行時にディスパッチされるのは インスタンスメソッド だけです。フィールド と 静的メソッド は宣言された型によって解決され、これが多くの人をつまずかせます。

class Parent {
    String label = "parent";
    String name() { return "Parent"; }
}

class Child extends Parent {
    String label = "child";          // 隠蔽するが、オーバーライドはしない
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent  - フィールドは宣言された型を使う
        System.out.println(p.name());   // Child   - メソッドは実行時の型を使う
    }
}

p.name() は Child のバージョンを実行しますが（ポリモーフィズム）、p.label は Parent のフィールドを読みます。フィールドはオーバーライドされるのではなく隠蔽されるからです。解決策は単純です。フィールドは private に保ち、メソッド経由でのみアクセスすれば、ポリモーフィックな呼び出しが常に勝ちます。

次へ：アクセス修飾子

ポリモーフィズムがきれいに機能するのは、サブクラスが正しいメンバーを見てオーバーライドでき、その一方でコードの他の部分が手を伸ばして不変条件を壊せない場合だけです。そのバランスは public、protected、private、そしてパッケージプライベートのアクセス、つまりアクセス修飾子によって制御されます。次はそれを見ていきます。