SRP は、モジュール内での責任は 1 つだけであるべきだと教えています。
ISP は、実際に必要以上のものに直面することを強いられるべきではないと言っています。print()
interface からメソッドを使用したい場合は、そのためにまたはクラスI
をインスタンス化する必要はありません。SwimmingPool
DriveThru
より具体的に言えば、それらは同じアイデアに対する異なる見解です。SRP はデザイナー側の視点により重点を置いていますが、ISP はクライアント側の観点により重点を置いています。 . だからあなたは基本的に正しいです。
それはすべてから来た
ISP は、Robert C. Martin が Xerox のコンサルティングを行っていたときに最初に使用および策定されました。Xerox は、一連の印刷された用紙のホチキス止めやファックス送信など、さまざまなタスクを実行できる新しいプリンター システムを作成しました。このシステムのソフトウェアはゼロから作成され、そのタスクを正常に実行しました。ソフトウェアが成長するにつれて、変更を加えることがますます難しくなり、最小の変更でも再展開サイクルに 1 時間かかるようになりました。これにより、開発を継続することがほぼ不可能になりました。設計上の問題は、ほとんどすべてのタスクで 1 つの主要な Job クラスが使用されていたことです。印刷ジョブまたはステープル ジョブを実行する必要があるときはいつでも、Job クラスの何らかのメソッドが呼び出されました。これにより、さまざまなクライアントに固有の多数のメソッドを持つ巨大な、または「太った」クラスが生まれました。
それで
Martin が提案した解決策は、今日では Interface Segregation Principle と呼ばれるものです。Xerox ソフトウェアに適用されると、Job クラスとそのすべてのクライアントとの間のインターフェイスのレイヤーが、依存関係逆転の原則を使用して追加されました。1 つの大きな Job クラスを持つ代わりに、Job クラスのメソッドを呼び出す Staple クラスまたは Print クラスによってそれぞれ使用される Staple Job インターフェイスまたは Print Job インターフェイスが作成されました。したがって、ジョブごとに 1 つのインターフェースが作成され、それらはすべて Job クラスによって実装されました。
@ http://en.wikipedia.org/wiki/Interface_segregation_principle#Origin