SOLIDでは、SRPとISPの違いは何ですか？ （単一責任の原則とインターフェイス分離の原則）
[〜＃〜] solid [〜＃〜] 「インターフェイス分離の原則」は「単一責任の原則」とどのように異なりますか？
ウィキペディア SOLIDのエントリ
ISPは、非常に大きいインターフェイスをより小さく、より具体的なインターフェイスに分割するため、クライアントは関心のあるメソッドについてのみ知る必要があります。
しかし、私には、SRPをクラスだけでなくインターフェイスにも適用しているように聞こえます。結局のところ、インターフェースが1つの概念的なことだけを担当している場合、それをさらに分解することはできません。
私は何かが足りないのですか、それともISPはSRPと冗長ですか？そうでない場合、ISPはSRPがそうではないことを何を意味しますか？
SRPは、モジュール内で1つの責任のみを持つ必要があることを示しています。
ISPは、実際に必要以上に直面することを強いられるべきではないと言っています。インターフェイスIからprint()メソッドを使用する場合は、そのためにSwimmingPoolまたはDriveThruクラスをインスタンス化する必要はありません。
より具体的に言えば、これらは同じアイデアに対する異なる見解です。SRPは設計者側の視点に重点を置いていますが、ISPはクライアント側の視点に重点を置いています。 。だからあなたは基本的に正しいです。
それはすべてから来ました
ISPは、Xeroxのコンサルティングを行うときに、Robert C.Martinによって最初に使用および策定されました。 Xeroxは、一連の印刷された紙のホチキス止めやファックスなどのさまざまなタスクを実行できる新しいプリンタシステムを作成しました。このシステムのソフトウェアはゼロから作成され、そのタスクを正常に実行しました。ソフトウェアが成長するにつれて、変更を加えることはますます困難になり、わずかな変更でも再展開サイクルが1時間かかるようになりました。これにより、開発を継続することがほぼ不可能になりました。設計上の問題は、1つのメインジョブクラスがほとんどすべてのタスクで使用されることでした。印刷ジョブまたはステープル留めジョブを実行する必要があるときはいつでも、Jobクラスのメソッドが呼び出されました。これにより、さまざまな異なるクライアントに固有の多数のメソッドを持つ巨大な「ファット」クラスが作成されました。この設計により、定番ジョブは、使用されていなくても、印刷ジョブのすべての方法を認識します。
そう
Martinが提案した解決策は、今日、いわゆるインターフェイス分離の原則です。 Xeroxソフトウェアに適用され、依存性逆転の原則を使用して、Jobクラスとそのすべてのクライアント間のインターフェイスのレイヤーが追加されました。 1つの大きなJobクラスを使用する代わりに、StapleクラスまたはPrintクラスがそれぞれJobクラスのメソッドを呼び出すために使用するStapleJobインターフェイスまたはPrintJobインターフェイスが作成されました。したがって、ジョブごとに1つのインターフェイスが作成され、すべてJobクラスによって実装されました。
@ http://en.wikipedia.org/wiki/Interface_segregation_principle#Origin
SRPは、モジュールの機能とその実行方法に関係しており、抽象化レベルの組み合わせを禁止します。基本的に、コンポーネントを1つの文で広範囲に定義できる限り、SRPを壊すことはありません。
一方、ISPは、モジュールの一部だけを消費することが理にかなっているのかどうか、ある側面を無視して、モジュールをどのように消費するかを懸念しています。
精神またはSRPを維持するが、ISPを破ることができるコードの例として、ファサードパターンがあります。 「より大きなサブシステムへの簡素化されたアクセスを提供する」という単一の責任がありますが、基盤となるサブシステムが大きく異なる考えを公開する必要がある場合、ISPを破壊します。
とは言うものの、通常、コードの一部がSOLIDの原則を破ると、多くの場合、ロット全体が破られます。特定の原則を破り、残りを維持する具体的な例は、実際にはまれです。
SRPとISPは、最終的には同じものになります。どちらかを実装するには、クラスまたはインターフェイスを分割する必要があります。
ただし、他の面では違いがあります。
- SRPに違反すると、設計構造全体に広範囲にわたる影響が及ぶ可能性があり、保守性、再利用性が低下し、もちろん凝集度と結合度が低くなります。
- SRPは、オブジェクト構造の動作コンポーネントと構造コンポーネントの両方に影響を与えます。
- SRP違反に関する再設計には、より詳細な分析が必要であり、設計のさまざまなコンポーネントを全体的に検討する必要があります。
ISPへの違反は、主に読みやすさの悪さ（そしてある程度は凝集度の低さ）に関するものです。しかし、メンテナンスとコードの再利用への影響は、SRPよりもはるかに不吉です。
さらに、コードをISPコンフォメーションにリファクタリングすることは、単なる構造上の変更のようです。
[〜＃〜] srp [〜＃〜] および [〜＃〜] isp [〜＃〜] については私のブログも参照してください。
ロバート・マーチン ツイート 2018年5月16日以下。
ISPは、インターフェイスのSRPに似ていると見なすことができます。しかしそれだけではありません。 ISPは一般的に、「必要以上に依存しないでください」と一般化します。 SRPは、「同じ理由で同時に変化するものを集める」と一般化しています。
プッシュとポップの両方を備えたスタッククラスを想像してみてください。プッシュするだけのクライアントを想像してみてください。そのクライアントがスタックインターフェイスに依存している場合は、popに依存しますが、これは必要ありません。 SRPはプッシュとポップを分離しません。 ISPはそうするでしょう。