インターフェース分離の原則(Interface Segregation Principle)とは？
SOLID原則のIにあたるものです。
「クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない」というインターフェースを作る際の原則
- クライアントが本当に必要としているインターフェースのみがクライアントから見える。
- インターフェース利用者の立場に立って最小限になっているか。
- クライアントは使用しないインターフェースの実装を強制されるべきではない。
- 一部未実装のメソッドになる場合、インターフェースを分けることを検討する。
ダメな例
複合機のインターフェースにprint、fax、scanというメソッドが定義されていますが、それを継承して使う具象クラスは必ずしも全てのメソッドを使うわけではありません。（印刷機能しかない複合機もあったりするようにです。）
また、今後新しく複合機に「シュレッダー機能」が追加されたとしたら全ての複合機にその機能を実装しないといけなくなってしまいます。
良い例
「クライアントが使う単位でインターフェースも分離してしまいましょう」という例になります。
このようなコードであればインターフェースの数が増えるのでソースの実装量が多少増えてしまう可能性はありますが、仕様変更に強いですし、初めて参画する方でもその部分だけを理解すれば良いので理解しやすいソースコードになります。（もちろん、全ての場合でインターフェースを分ければ良いというわけではなく主にSOLIDの基本ユースケースであるバリエーションがあるコードが主な用途にはなってくるのでそこは意識しましょう。）
フロントエンド開発において
昨今であればVueやReactなどのフロントエンド開発にはTypeScriptを使うことも多いかと思いますが、フロントのコンポーネント側のpropsの引数のインターフェース定義にもこの原則は活用できます。(使わないメソッドを排除しようというだけではない。）
propsのinterfaceを複数コンポーネントで汎用化させすぎていると「このコンポーネントではこのpropsは本当に使っているのか？」などと疑問を感じながら開発を進めることになってしまうので自然とインターフェース分離の原則を意識して実装していることも多いのではないかと思います。
また、重複はできるだけ排除するという考え方にも一部反する概念かもしれませんがその辺との共存なども経験を積んで判断スキルを高める必要があると思います。
この記事へのコメントはありません。