Clean Architecture インターフェイス分離の原則

インターフェイス分離の原則

 複数のユーザーが同じOPSクラスを使用している。ここでは、User1がop1を使い、User2がop2を使い、User3がop3を使用しているものとする。

 User1のソースコードは、実際には使っていないop2とop3にも意図せずに依存。ここでいう「依存」とは、op2のコードを変更したときに、User1の再コンパイルと際デプロイが必要になるという意味。本来ならば、op2のコードが変わっても気にする必要はない。

 この問題を解決するには、各操作をインターフェイスに分離する。

 User1のソースコードはU1Opsとop1には依存しているが、OPSには依存していない。つまり、OPSに変更があったとしても、もしそれがUser1に関係のない部分であれば、User1の再コンパイルと再デプロイは不要になる。

インターフェイス分離の原則(ISP)とアーキテクチャとの関係

 システムSを担当するアーキテクトが、あるフレームワークFをシステムに導入したいと考えたとする。このフレームワークFの作者は、フレームワークを特定のデータベースDのためだけに作っている。つまりSはFに依存しており、さらにFはDに依存していることになる。

問題のあるアーキテクチャ

 FがDのすべての機能を使っているわけではなく、使っていない機能もある。Sにとって、それらの機能はどうでもいい。だが、Dのそのような部分が更新されると、Fは再デプロイすることになる。それはすなわち、Sも再デプロイしなければいけないということ。Dの一部の機能に障害が発生すると、それがFやSの障害の原因になってしまう可能性がある。

まとめ

 必要としないお荷物を抱えたものに依存していると、予期せぬトラブルの元につながる。