CleanArchitecture憧れ系なんだけど、凄く重要な要素なのに、Rubyエンジニアだから実感がわかない「インターフェース」について、考え方の整理もかねて、自分なりの解釈を纏めなおしてみた。

インターフェースの役割の復習

依存関係の整理による保守性の確保

「変更の可能性が高いコードをインターフェースの向こう側に閉じ込めてしまう」事で、保守が容易になる。

無インターフェース例

Aクラスは、Bクラスを使っている。
ある時、Bクラスの実装が大幅に変更された。（これをB'クラスとする）
この時、Aクラスのコードは、どうなるか？

もしかすると大幅な変更が必要かもしれないし、もしかすると何も変えずに済むかもしれない。
それを知るためには、AはBにどうメッセージを投げていて、Bはどうそれを受けていて、B'ではどう変更されているのか等、関連するクラスの全てを調べ直す必要がある。

つまりAは、Bの存在自体に、大きな影響を受けていると言える。

この様に、AがBを前提に書かれている場合、「AはBに依存している」という。

コードの再調査は、大変な作業だ。
クラスが2つなら良いが、大規模なシステムになると、依存関係は急激に複雑になる。
Bに依存しているクラスはAだけではなく、5個10個と出て来るかもしれないし（Anとする）、Anの変更も必要であれば、Anに依存しているクラスもまた洗い出し、全て再調査する必要がある。

とてもやっていられない。
なので、この依存関係は、システムが巨大化していく段階のどこかで、あらかじめ断ち切っておく必要がある。

その為に使う武器の一つが「インターフェース」になる。

インターフェース例

AクラスとBクラスを「インターフェース」を用いた実装で考えると、例えば以下の様になる。

Aクラスは、Iインターフェースを使用している。
Iインターフェースの実態は、Iインターフェースの仕様通りに実装された、Bクラスである。

ある時、Bクラスの実装が大幅に変更された。（これをB'クラスとする）
この時、Aクラスのコードはどうなるか？

何も変えないで済む。
何故なら、BクラスがB'クラスになっても、Iインターフェース自体は何も変更されていないからだ。
B'クラスはIインターフェースの仕様を忠実に守りつづけなければ、Iインターフェースの実態となる事が出来ない。

AはIを使うため、Iに依存している。さらは、BもIの仕様を守るため、Iに依存している。
処理自体ではAがBを使用しているのだが、「依存は、AもBも、Iにのみしている」。

BではなくIに依存しているため、AはBの変更の影響を受けない。
影響を受けないから、BがB'になっても、AやAnの再調査は必要が無い。
当然、それらに依存している無数のクラスの再調査も必要が無い。

とても修正が簡単になる。
Bを修正する時は、Bの事だけを考えていれば良い。

まとめ

「変更の可能性が高いコードをインターフェースの向こう側に閉じ込めてしまう」事で、コードが保守しやすくなる。
- これを実現するために、依存をインターフェースに集める様に実装しておく

依存関係の整理による拡張性の確保

「拡張の可能性が高いコードをインターフェースの向こう側に置いておく」事で、保守が容易になる

無インターフェース例

AクラスがBクラスを使用している。
ある時、新しくC機能が必要になった。
C機能はBクラス（この機能をB機能とする）と良く似た性質を持っており、B機能とは排他的に実行される。

この時、C機能はどの様に実装されるか？

どの様にでも書く事が出来る。

Aクラスに手続き的に追加されるかもしれないし、Cクラスを追加してAクラスから呼び出すのかもしれない。
もしくは、Bクラスの中でB機能とC機能の実行分岐が追加されるのかもしれない。

どういう形でも実現が可能だが、どの場合でも、それぞれのクラスに、大幅な修正や構成変更が必要になる。そして、依存関係は断ち切れていないので、その影響範囲は無限に広い。

これがC機能だけなら良いが、D機能、E機能と拡張機能が追加される様な事があると、修正箇所が爆発的に増え、手に負えなくなる。
機能の拡張は、簡単に行える様にしておく必要がある。

そのための武器の一つとして、ここでも「インターフェース」を用いる事が出来る。

インターフェース例

AクラスとBクラスを「インターフェース」で実装すると考えると、例えば以下の様になる。

Aクラスは、Iインターフェースを引数から取得している。
Aクラスは、Iインターフェースの関数を実行している。
Iインターフェースの実態は、Iインターフェースの仕様通りに実装された、Bクラスである。

ある時、新しくCという機能が必要になった。
C機能はBクラス（この機能をB機能とする）と良く似た性質を持っており、B機能とは排他的に実行される。

この時、C機能はどの様に実装されるか？

どの様にでも書く事が出来る。
が、簡単に解決する方法がある。

Cクラスを、Iインターフェースの仕様通りに実装する。
A機能に引数として渡すIインターフェースの実態を、BもしくはCクラスとする。

この方法であれば、AクラスもBクラスも、何も修正をする必要が無い

Bとはそもそもが別クラスだし、AはあくまでIインターフェースを使用しているのだから、その実態がBでもCでも関係が無い。

どういう形でも実現が可能だが、この実装をした場合に、影響範囲を最低限に抑える事が出来る。
例えD機能、E機能と拡張機能が追加される事があっても、D/Eそれぞれについて、クラスとIインターフェース作成時の分岐を追加するだけで、実装を終える事が出来る。
とても拡張が簡単になる。

機能拡張に必要な作業は、以下の2つとして纏められる

新機能クラスを追加
インターフェース作成時に、新機能クラス用の分岐を追加
- インターフェースの作成場所は、それ専用のクラスとする

まとめ

「拡張の可能性が高いコードをインターフェースの向こう側に置いておく」事で、拡張が容易になる
- これを実現するためには、クラスをインターフェース経由で呼び出すように実装しておく

※注
（インターフェースではなく、facadeパターンを使う手もあった。この構成であればそれだけで良いのかも）
（インターフェースは引数ではなく、factoryクラスで実態クラスを分岐させる方が綺麗な気もする）

インターフェースまとめ

インターフェースの目的は以下の2つ

「変更の可能性が高いコードをインターフェースの向こう側に閉じ込めてしまう」事で、保守を容易にする。
「拡張の可能性が高いコードをインターフェースの向こう側に置いておく」事で、拡張を容易にする。

そのために必要な実装方針は、以下の2つ

変更の可能性が高いコードは、直接使用するのではなくインターフェース経由で呼び出す。
拡張の可能性が高いコードは、直接使用するのではなくインターフェース経由で呼び出す。