インターフェース分離原則
Interface Segregation Principle
クライアントは自分が使わないメソッドに依存することを強制されない
注意として、「クライアント」とはお客さんのことではないです。あるクラスを使っているプログラムと考えてください。
SOLID原則と呼ばれる、主要５原則のひとつ。
SOLID原則
目次
どんなときに使うの？
使っていないインターフェースに振り回されるとき
コモンさんユーティリティクラス、通信メソッド修正したんでリリースしまーす
コモンさんユーティリティクラス、ファイル出力メソッド修正したんでリリースしまーす
リーダーさんそのメソッド、どれも使ってないんだけど…
共通的に使うクラスがあったとして
- そのクラスは使っている
- けど、100個のうちのメソッドのうち１個しか使ってない
といったとき、そのクラスの修正が、影響なさそうに思えるが影響ないとも断言できない、というもどかしい状況になることあります。
ファットインターフェースの問題点
インターフェースは少ないほうがいい
他のクラスとの接点のことを「インターフェース」といいます。ほかのクラスから呼ばれるようなパブリックメソッドなどですね。
インターフェースが少ないほど、それぞれのクラスの独立性が高くなる。これは容易に想像できますね。
逆に、そのようなインターフェースが多いさまを「ファットインターフェース」といいます。
ファットインターフェースになりがちなクラス
以下のような名前のついたクラスは、ファットインターフェースになりがちです。注意しましょう。
ファットインターフェースになりがちクラス
- Utilityクラス ファイル読み書き、通信、DB操作など、便利な処理を集めたユーティリティクラス。あらゆるツールが詰め込まれがち。
- Managerクラス 処理を統括するマネージャークラス。なにか分類に困った処理はマネージャーがやる。スーパープレイングマネージャー誕生。
- Commonクラス Commonには、なにが入ってもおかしくない。ごった煮クラスのできあがり。
インターフェースを分離しよう
それを使うクラス（クライアント）が本当に必要としているインターフェイスのみが、クライアントから見えているのがベストです。使わないメソッドに振り回されないようにして、変更の伝播を最小限に食い止めます。
まとめ
この原則は、つまるところ、単一責任原則に従いましょう、という意味でもあります。
そのクラス、ファットインターフェースになっていないか、注意しましょう。
コメント