【Java進化史 第22回 前編】Java8 〜 インターフェースに実装を書く？defaultメソッドはアリなのか 〜

【Java進化史 第22回 前編】Java8 〜 インターフェースに実装を書く？defaultメソッドはアリなのか 〜

若手のコードを見て、手が止まった。

public interface Calculator {

    int add(int a, int b);

    default int subtract(int a, int b) {
        return a - b;
    }
}

class SimpleCalculator implements Calculator {

    @Override
    public int add(int a, int b) {
        return a + b;
    }
}

ここでの読み方はこうだ。

add は従来どおり「実装必須」の抽象メソッド。

一方、default が付いた subtract は、 インターフェース側にあらかじめ実装が用意されている。

実装クラスが独自に書かなければ、 そのままこの処理が使われる。

つまり、インターフェースが 「振る舞いの雛形」を持っている、ということになる。

あれ？

実装していいの？

インターフェースに、処理が書いてある。

しかも、実装クラスでは add しか書いていない。 subtract は自動的に使えてしまう。

正直に言えば、違和感しかなかった。

インターフェースとは「契約」だ。

何をするかを定義する場所であって、 どうやるかを書く場所ではない。

少なくとも、私たちはそう教わってきた。

■ なぜ実装を書かなかったのか

理由は単純だ。

責務を分けるためである。

• インターフェース ＝ 振る舞いの定義（契約）
• クラス ＝ 具体的な実装

役割を分離することで、 設計は明確になり、 依存関係も整理される。

そして何より、 カプセル化が守られる。

■ カプセル化と保守性

実装の詳細はクラス内部に隠される。

外部から見えるのは、 メソッドのシグネチャだけ。

だから、保守性と利用者視点の可読性が守られていた。 実装が隠蔽されていることで、変更の影響範囲は実装クラス内部に閉じ込められる。 利用者は契約（インターフェース）だけを読めばよく、それが長年Javaの安定性を支えてきた。

ただし、これは「半分は真実」である。

確かに利用者にとっては読みやすい。 しかし、実装を探すためにクラスを辿らなければならない場面も多かった。

設計が崩れれば、 インターフェースはただの形式だけになってしまう。

■ それでも守られてきた原則

それでも、 「インターフェースに実装を書かない」 という原則は長く守られてきた。

それは単なる文法上の制約ではない。

Javaという言語が大規模開発で信頼されてきた、 ひとつの思想だった。

次回、実際に書いて確かめてみる。