【オブジェクト指向プログラミング】誰のもの？で理解するインターフェース

前置き

背景

オブジェクト指向プログラミングのインターフェースについて、以下のような例で学んだ方は多いのではないでしょうか。

public interface Animal {
    void bark(); 
}

public class Dog implements Animal {
    void bark() {
        System.out.println("ワン");
    }
}

public static void main(String[] args){
　　Animal animal = new Dog(); // Animal型の変数にDogインスタンスを代入できる
　　animal.bark();
}

上記は極端な例ですが、

• 「 Dog dog = new Dog(); と比べて何がいいの？」
  という疑問に答えてくれる情報をなかなか見つけることができず、言語仕様と割り切って覚えてきた方は、実際に多いのではないでしょうか。

筆者は、「エンタープライズアプリケーションアーキテクチャパターン」「GoFデザインパターン」「実践UML」「Object Design」「実装パターン」「アジャイルソフトウェア開発の奥義」「オブジェクト指向入門」「ドメイン駆動設計」などなど、名高いオブジェクト指向の古典を20冊以上読んできました。（※）

この記事では、元オブジェクト指向原理主義厨である筆者が、インターフェースを解説し、読者の方にインターフェースの本当の使い方を理解いただきます。

※現代に生きる皆さんがこうした古典を何冊も読むことは、推奨しません。現代においても通用するエッセンスはごく僅かなためです。この記事を読めば十分と思います。

指針

私はインターフェースを定義するとき、「インターフェースは誰のもの？」ということについて、強くイメージしています。
この感覚をシェアすることで、インターフェースについて皆さんの理解が深まると考えます。

この記事では、前半で「インターフェースは誰のもの？」というテーマでインターフェースという概念を深く理解いただき、後半でケーススタディをなぞることで、実際にどのように便利に使うことができるのかを理解いただきます。

想定読者

以下のような方を読者として想定しています。

• 言語仕様は分かっているものの、いまいちインターフェースの使い道が分かっていない初学者
• 今までなんとなくインターフェースを使ってきた、あるいは避けてきたエンジニア

インターフェースの言語仕様を押さえていることが前提です。
※どの言語でも構いません。

【経験者の方向け】
オブジェクト指向プログラミングの経験者の方向けの記事ではありませんので、ご注意ください。
主にDIや依存性逆転のためにインターフェースを活用するユースケースをターゲットに解説しています。

この記事のゴール

ゴールは以下になります。

• 「インターフェースって言語仕様としては分かるけど、実際どういうときに使うんだろう？」という疑問を解消し、腹落ちいただくこと

以下はこの記事のスコープではありません。

• 具体的なドメイン（要件）に対して、どのようにモデリングしてコードに落とすべきか

サンプルコードの言語

オブジェクト指向プログラミングにおけるインターフェースを具体的に理解するために、サンプルコードを用いています。TypeScript風言語で記載します。

1. 前半：インターフェースは誰のもの？

1-1. サンプルコード

「インターフェースは誰のもの？」について考えるために、以下をサンプルコードとします。

Dogはワンなど、鳴き声を管理する責務を持っています。SomePersonは聞き取った物事を聞き取って何かをする責務を持っています。

そして、Personインターフェースを定義しています。

※もちろんコードがこれだけであれば、インターフェースを定義することに大きな意味はありません。あくまでサンプルです。

[型]

class Dog {
  bark(target: Person) {
      target.hear('ワン');
  }
}

interface Person {
    hear(sound: string): void;
}

class SomePerson implements Person {
    hear(sound: string) {
        console.log(sound)
    }
}

[スクリプト]

const dog = new Dog();
const person = new SomePerson();
dog.bark(person); // console.log("ワン")となる

1-2. クイズ：インターフェースは誰のもの？

本題の「インターフェースは誰のもの」について、解説を見る前に30秒くらい時間を取って考えてみていただきたいです。

このPersonインターフェースは、SomePersonのものでしょうか？それともDogのものでしょうか？

もしフォルダを分けるとしたら、インターフェースはどちらに入れますか？

1-3. 正解発表

正解は、Bです。

もちろん絶対的正解はありませんが、通常のアプリケーション開発であれば、Bが正解になることが多いです（細かいことは割愛します）。

ここで迷いなくBを選べた方は、この記事を読む必要はないかもしれません。

ここで迷った方やAを選んでしまった方は、最後まで読んでいただきたいです。

1-4. 解説

現実世界のたとえ話でイメージを膨らませるところから始めます。

1-4-1. 現実世界の例でイメージを膨らませる

例えばここにType-Cで充電できるPCと、周辺機器メーカの充電器があるとします。

このとき、「充電器はこのような規格で接続する」という制約は、PC側が提示するものです。Mic●osoftがPCを作って、取扱説明書や仕様書に「充電はこのような規格であるべき」と記載しているはずです。

そしてエ●コム社がその制約を満たすように充電器を作っているため、この充電器でPCを充電することができます。

この図における、「充電器はこう」というPC側が提示している制約が、オブジェクト指向プログラミングにおけるインターフェースのイメージに近いです。

※現実世界では、Type-Cなど標準化された規格に依存する形でPC側も充電器側も作っているため、この例はベストではないかもしれません。ここでは、Mic●soft社のPCが世界に1つだけのオレオレ規格を定義しており、エ●コム社の充電器はそのPCのためだけに作られているものと考えてください。

1-4-2. Dogの例を理解する

コードでインターフェースを定義するときの感覚は、上記の構造に良く似ています。

この構造をDogの例に適用すると、次のようなイメージになります。

PersonインターフェースがDogのものである、という感覚がお分かりいただけますでしょうか。

このイメージを見た上で、もう一度コードを眺めてみてください。
DogとPersonの強い結びつきが見えてくるかと思います。

[型(再掲)]

class Dog {
  bark(target: Person) {  // DogにとってのPersonを受け取る
      target.hear('ワン');
  }
}

// DogにとってのPersonはこう
interface Person { 
    hear(sound: string): void;
}

// DogにとってのPersonを満たす(実装する)
class SomePerson implements Person { 
    hear(sound: string) {
        console.log(sound)
    }
}

[スクリプト(再掲)]

const dog = new Dog();
const person = new SomePerson();
dog.bark(person); // DogにとってのPersonを実装する、SomePersonインスタンスを渡す

注意

• 例えばDogインターフェースがあったとしたら、それはおそらくPersonのもので、関係性が逆になります。

2. 後半：インターフェースの使い方

ここまで理解できれば、インターフェースが価値を発揮するケースを理解することができます。

ケーススタディ形式で説明します。

インターフェースがない状態から始め、改修が発生し、インターフェースを導入する流れを見ていきます。

2-1. 概要

吠えられたらコンソールにログを吐くのではなく、脳内に記憶するタイプのPersonを導入したくなったとします。

2-2. サンプルコード

先程の例から、インターフェースを取り除きます。
DogはSomePersonを受け取っています。

[型]

class Dog {
  bark(target: SomePerson) {
      target.hear('ワン');
  }
}

class SomePerson {
    hear(sound: string) {
        console.log(sound)
    }
}

[スクリプト]

const dog = new Dog();
const person = new SomePerson();
dog.bark(person); // console.log("ワン")となる

interface定義を抜いただけに見えますが、インターフェースが誰のものかを意識できるようになると、クラスの関係性が全く異なることに気がつくと思います。

先程のイメージと比べてみてください。

2-3. 改修手順

2-3-1. MemorizingPersonを定義する

インターフェースを定義しないまま、サンプルコードに新しくMemorizingPersonを追加します。

新しいPersonの定義自体は、これで完了です。

[型]

...

// 脳内に記憶するPerson
class MemorizingPerson {
    sounds:string[] = [];
    hear(sound: string) {
        this.sounds.push(sound);
    }
}

2-3-2. 定義したクラスを使う（エラー発生）

これらのクラスを使って以下のようなスクリプトを書きます。

[スクリプト]

const dog = new Dog();
const somePerson = new SomePerson();
const memorizingPerson = new MemorizingPerson();
dog.bark(somePerson)
dog.bark(memorizingPerson); // ここでエラー
dog.bark(memorizingPerson); // ここでエラー

for (const sound of memorizingPerson.sounds) {
    console.log('memory: ' +sound)
}

このようなコードは、機能しません。
Dogは引数として具体的にSomePersonを指定しており、MemorizingPersonはSomePersonの一種ではないためです。

例えば普通の静的型付け言語だと、コンパイルエラーになります。

2-3-3. インターフェースを導入する

ここで、インターフェースを導入します。

DogがSomePersonに依存するのではなく、DogはPersonというインターフェースを宣言し、SomePersonやMemorizingPersonがこのインターフェースを満たしに来るようにします。

このとき、頭の中に以下のようなイメージを描きます。

コードにすると次のようになります。

[型]

class Dog {
  bark(target: Person) {
      target.hear('ワン');
  }
}

interface Person {
    hear(sound: string): void;
}

class SomePerson implements Person {
    hear(sound: string) {
        console.log(sound)
    }
}

class MemorizingPerson implements Person {
    sounds:string[] = [];
    hear(sound: string) {
        this.sounds.push(sound);
    }
}

これにより、以下のコードは機能するようになります。
改修はこれで完了です。

[スクリプト(再掲)]

const dog = new Dog();
const somePerson = new SomePerson();
const memorizingPerson = new MemorizingPerson();
dog.bark(somePerson) // DogにとってのPersonを実装する、SomePersonインスタンスを渡す
dog.bark(memorizingPerson); // DogにとってのPersonを実装する、MemorizingPersonインスタンスを渡す
dog.bark(memorizingPerson); // 同上

for (const sound of memorizingPerson.sounds) {
    console.log('memory: ' +sound)
}

フォルダを分けるなら、クイズから学んだとおり、以下のような構成になります。

これで、このケーススタディは完了です。

2-4. インターフェースによって何が得られたか

インターフェースを導入したことで、Dogクラスは複数のPersonクラスの実装と一緒に使うことができるようになりました。

加えて、今回はインターフェースを導入するためにDogクラスの改修が必要になりましたが、今後はDogを一切改修せずに新しいPersonを定義できるようになったことも、大きなメリットです。（疎結合性）

例えばDogクラスのみをライブラリとして世界に公開するとします。

ライブラリは全世界で使われるため、ライブラリの利用者が定義するPersonに応じて、都度Dogを改修するわけにはいきません。

このような場合、DogにとってのPersonインターフェースを定義することは不可欠になります。

まとめ

「誰のもの？」を意識するようにすることで、インターフェースを上手く定義することができます。

Dogクラス、SomePersonクラス、Personインタフェースがあれば、PersonインターフェースはたいていDogクラスのものです。

飼い主クラス、ペットインターフェース、Someペットクラスがあれば、ペットインターフェースはたいてい飼い主クラスのものです。

インターフェースから得られるのは、疎結合性です。今回の例では、Dogクラスに一切修正を加えず、新たなPerson実装クラスを定義し、連携させて使うことができるようになります。

細かいことを言えばインターフェースの使われ方はこれだけではありません。しかし、この使い方が理解できていれば、インターフェースの価値を最大限に発揮させることができます。

追伸

この記事はMagicodeから移転しました。
2022年9月あたりの記事となります。

よければTwitterもフォローお願いします！
@sumiren_t