2015の2015年12月24日公開記事です。Laravelも契約(インターフェイス)の使用を勧めているのか...参照:Laravel5.1:契約Laravelリファレンスも勧めているらしいし、やってみるか...そして、クラス間を全部インターフェイス経由で実装します。インターフェイスにより、クラス間の「契約」を使えばいいというわけでありません。Laravelのソースの読み方の記事とIDEをおすすめする記事でもお伝えした通り、副作用があります。読みづらくなる、追いづらくなる複雑になるインターフェイスを利用する目的は「クラス間の関係」を弱くし、「クラス交換性」を上げることです。した目的のため、欠点をどれだけ容認できるかという「トレードオフ」で使用するかどうかを決めましょう。(実際、アルゴリズムからプログラムパターン、実生活でのお金の使い方など、ほぼ全ては「トレードオフ」の結果です。)たとえば、わずかな将来の入れ替えの可能性を考えるのであれば、存在するクラスは全て交換できるように作成する必要が起きるでしょう。手間も実行コストも増えます。そんなばかなことはしないのです。独立させ、交換性を高めることで利益を得られる箇所にだけ導入しましょう。どこを粗結合にするかインターフェイスによる契約は、目的がはっきりしていますので、どこで適用すべきかわかりやすいですね。交換する必要が起きる場所たとえばMVCであれば、それぞれは独立しています。作成する場合はフレームワークへおんぶに抱っこしますから、意識しないでしょうが、個人でMVC構造から組み上げるのであれば、それぞれは独立していますので、そのクラス間をインターフェイスにより定義できます。フレームワークを使うためのロジックとアプリケーションのビジネスロジック間にも採用できます。すれば、フレームワークを交換可能にできます。外部Webサービスを使用する場所は、必須ですね。長期的に持続することが約束されているサービスであればともかく、現状のWebサービスは将来も持続するかどうかは、分かりません。廃止時や停止時に困らないように、交換可能にしておくべきでしょう。した指針には幅があり、どのプロジェクトにも適用できるわけでありません。プロジェクトに数百のインターフェイスがあったら、多分それはもうやり過ぎです。コンテナなどを利用し、インターフェイスに対するインスタンス化手順や実体を定義しているのなら、コードを追いかけるのに骨を折るため、メンテナンス性が極端に落ちます。どんな素晴らしい指針でも、やり過ぎにはご注意を。