インターフェース

前の章の最後に残した違和感を回収します。通知システムの親クラス Notification の send は「とりあえずの実装」で、実際に使われることはありませんでした。欲しかったのは実装ではなく、「sendというメソッドを持っていること」という約束だけ。

その「約束だけ」を書くための道具がインターフェースです。現代のオブジェクト指向で、おそらく一番の働き者です。この章を越えると、後で出てくる設計原則とデザインパターンの話が全部つながるようになります。

interfaceは、約束だけを書く

構文から見ます。interface は、メソッドの名前と型だけを並べたものです。中身(実装)は書きません。

interface Notifier {
  send(message: string): void;
}

「Notifierであるとは、send(message: string): void というメソッドを持っていることである」。これだけです。設計図ですらなく、資格の要件のようなものだと思ってください。

クラスがこの約束を守ることを宣言するキーワードが implements です。前の章の通知システムを、親クラスなしで書き直します。

動きは前の章とまったく同じです。違いは構造にあります。「とりあえずの実装」を持つ親クラスが消え、代わりに **約束(Notifier)**が置かれました。各クラスは何も受け継いでいません。ただ「私はsendを持っています」と宣言し、実際に持っているだけです。ポリモーフィズム(Notifier[] に混ぜて一括処理)は、継承がなくても成立する。これがこの章の第一の発見です。

implements には監視役の顔もあります。約束を破る、たとえば send を書き忘れたり、引数の型を間違えたりしたクラスを書くと、その場で型エラーになります。「Notifierを名乗るならsendを正しく持て」とコンパイラが見張ってくれるのです。

extends と implements の整理

似た位置に書く2つのキーワードを、ここで整理しておきます。