インターフェイスの活用し過ぎにご注意

タグ： Laravel  

これはLaravelリファレンス発売記念！販売促進！！ Advent Calendar 2015の2015年12月24日公開記事です。

そうか、Laravelも契約（インターフェイス）の使用を勧めているのか…

Laravelリファレンスも勧めているらしいし、やってみるか…

そして、クラス間を全部インターフェイス経由で実装します。すると「なんだか複雑になった…」、「読みづらい…」ということになります。

副作用

滅多矢鱈にインターフェイスにより、クラス間の「契約」を使えばいいというわけでありません。Laravelのソースの読み方の記事とIDEをおすすめする記事でもお伝えした通り、副作用があります。

  • 読みづらくなる、追いづらくなる
  • 複雑になる

インターフェイスを利用する目的は「クラス間の関係」を弱くし、「クラス交換性」を上げることです。こうした目的のため、欠点をどれだけ容認できるかという「トレードオフ」で使用するかどうかを決めましょう。（実際、アルゴリズムからプログラムパターン、実生活でのお金の使い方など、ほぼ全ては「トレードオフ」の結果です。）

たとえば、わずかな将来の入れ替えの可能性を考えるのであれば、存在するクラスは全て交換できるように作成する必要が起きるでしょう。手間も実行コストも増えます。ですから、そんなばかなことはしないのです。独立させ、交換性を高めることで利益を得られる箇所にだけ導入しましょう。

どこを粗結合にするか

インターフェイスによる契約は、目的がはっきりしていますので、どこで適用すべきかわかりやすいですね。

  • 機能的に独立してる箇所の連携
  • 交換する必要が起きる場所

たとえばMVCであれば、それぞれは独立しています。ちゃっちゃと作成する場合はフレームワークへおんぶに抱っこしますから、意識しないでしょうが、個人でMVC構造から組み上げるのであれば、それぞれは独立していますので、そのクラス間をインターフェイスにより定義できます。

フレームワークを使うためのロジックとアプリケーションのビジネスロジック間にも採用できます。そうすれば、フレームワークを交換可能にできます。

外部Webサービスを使用する場所は、必須ですね。長期的に持続することが約束されているサービスであればともかく、現状のWebサービスは将来も持続するかどうかは、分かりません。廃止時や停止時に困らないように、交換可能にしておくべきでしょう。

もちろん、こうした指針には幅があり、どのプロジェクトにも適用できるわけでありません。

ですがもし、プロジェクトに数百のインターフェイスがあったら、多分それはもうやり過ぎです。コンテナなどを利用し、インターフェイスに対するインスタンス化手順や実体を定義しているのなら、コードを追いかけるのに骨を折るため、メンテナンス性が極端に落ちます。

どんな素晴らしい指針でも、やり過ぎにはご注意を。