インターフェイス分離原理ISPインターフェイス分離原理は、複数の専用インターフェイスを使用することが単一の合計インターフェイスを使用するよりも優れていることを提唱しています。
あるクラスの別のクラスへの依存性は、最小のインターフェイスに確立する必要があります。
インターフェイスは役割を表し、異なる役割をインターフェイスに引き渡すべきではありません。無関係なインターフェイスがマージされて肥大化した大きなインターフェイスが形成されます。これは、役割とインターフェイスへの汚染です。
「顧客は、使用していない方法に依存することを強制されるべきではありません。インターフェイスは、クラスの階層ではなく、顧客に属します。」これは非常に明確です。簡単に言えば、顧客が使用しない方法を使用するように強制しないでください。ユーザーが使用しない方法を使用せざるを得ない場合、これらの顧客は、使用しないこれらの方法の変更によって引き起こされる変更に直面します。
ユースケースでは、発信者が必要とする方法を提供し、不要な方法をブロックします。インターフェイス分離の原則を満たしています。たとえば、eコマースシステムには、注文カテゴリで使用される3つの場所があります。
インターフェイス分離原理（ISP）によると、あるクラスの別のクラスへの依存性を最小のインターフェイスに確立する必要があります。
つまり、ポータルの場合、クエリメソッドを使用したインターフェイスにのみ依存することができます。
UML構造は次のとおりです。
インターフェイス分離の原理を無視するJavaインターフェイスライティングの例を見てみましょう。
インターフェイスi {public void method1（）; public void method2（）; public void method3（）; public void method4（）; public void method5（）; } class A {public void depend1（i i）{i.method1（）; } public void depent2（i i）{i.method2（）; } public void depent3（i i）{i.method3（）; }} class bはi {public void method1（）{system.out.println（ "method1"をインターフェイスI "）;} public void method2（）{system.out.println（"クラスB実装インターフェースI "）メソッド4とメソッド5は、これらの2つのメソッドの本文が空であっても、インターフェイスA、// } public void depent3（i i）{i.method5（）;} class dはi {public void method1（）{system.out.println（ "method1"を実装するためのInterface i "）; } //クラスD、Method2、およびMethod3の場合は必要ありませんが、インターフェイスAにこれらの2つのメソッドがあるため、//これらの2つのメソッドのメソッド本体が実装プロセス中に空であっても、効果がないこれら2つのメソッドを実装する必要があります。 public void method2（）{} public void method3（）{} public void method4（）{system.out.println（ "クラスDの方法4を実装するインターフェイスi"）; } public void method5（）{system.out.println（ "クラスDの方法5を実施するインターフェイスi"）; }} public class client {public static void main（string [] args）{a a = new a（）; a.depend1（new B（））; a.depend2（new B（））; a.depend3（new B（））; c c = new c（）; c.depend1（new d（））; c.depend2（new d（））; c.depend3（new d（））; }}インターフェースがインターフェイスに表示されている限り、インターフェイスがあまりにも肥大化している場合、それらに依存するクラスに役立つかどうかにかかわらず、これらのメソッドは実装クラスで実装する必要があることがわかります。これは明らかに良いデザインではありません。この設計がインターフェイス分離の原理に準拠するように変更されている場合、インターフェイスIは分割する必要があります。ここでは、元のインターフェイスIを3つのインターフェイスに分割します。スプリットデザインは、下の図に示されています。
いつものように、クラス図に慣れていない友人のために参照のためにプログラムコードを投稿してください。
インターフェイスi1 {public void method1（）; } interface i2 {public void method2（）; public void method3（）; } interface i3 {public void method4（）; public void method5（）; } class A {public void depend1（i1 i）{i.method1（）; } public void depent2（i2 i）{i.method2（）; } public void depent3（i2 i）{i.method3（）; }} class bはi1、i2 {public void method1（）{system.out.println（ "クラスBの方法1を実装しますインターフェイスi1"）; } public void method2（）{system.out.println（ "クラスBの方法2を実装しますインターフェイスi2"）; } public void method3（）{system.out.println（ "クラスBの方法3はインターフェイスi2"）; }} class c {public void depend1（i1 i）{i.method1（）; } public void depent2（i3 i）{i.method4（）; } public void depent3（i3 i）{i.method5（）; }} class dはi1、i3 {public void method1（）{system.out.println（ "クラスDの方法1を実施するインターフェイスi1"）; } public void method4（）{system.out.println（ "クラスDの方法4を実施するインターフェイスi3"）; } public void method5（）{system.out.println（ "クラスDの方法5を実装しますインターフェイスi3"）; }}インターフェイス分離の原理の意味は、単一のインターフェイスを確立し、巨大で肥大化したインターフェイスを確立せず、インターフェイスを改良し、インターフェイス内のメソッドを少なくしようとすることです。言い換えれば、呼び出すために依存するすべてのクラスの巨大なインターフェイスを確立しようとするのではなく、各クラスに専用のインターフェイスを確立する必要があります。この例では、3つの専用インターフェイスに巨大なインターフェイスを変更すると、インターフェイス分離の原則が採用されます。プログラミングでは、いくつかの専用インターフェイスに依存することは、1つの包括的なインターフェイスに依存するよりも柔軟です。インターフェイスは、設計中の外部設定に設定された「契約」です。複数のインターフェイスを定義することにより、外部の変化の拡散を防ぎ、システムの柔軟性と保守性を改善できます。
これについて言えば、多くの人々は、インターフェイス分離の原則は以前の単一責任の原則と非常に似ていると感じるでしょうが、そうではありません。第一に、単一の責任の原則は責任に焦点を当てています。一方、インターフェイス分離の原理は、インターフェイス依存性の分離に焦点を当てています。第二に、単一の責任の原則は主に制約クラスであり、その後にプログラムの実装と詳細を目的としたインターフェイスとメソッドが続きます。一方、インターフェイス分離の原理は、主に抽象化を目的としたインターフェイスインターフェイスを主に制約し、プログラムフレームワーク全体の構築を目的としています。
インターフェイス分離の原理を使用してインターフェイスを制約する場合、次のポイントに注意する必要があります。
インターフェイスはできるだけ小さくする必要がありますが、制限される必要があります。インターフェイスを改善することは、プログラミングの柔軟性を向上させることができます。それは有益ではないという事実ですが、小さすぎるとインターフェイスが多すぎて設計が複雑になります。したがって、それは中程度でなければなりません。
インターフェイスに依存するクラスのカスタマイズされたサービス、呼び出されたクラスに公開する必要がある方法のみ、必要ではない方法が非表示になります。モジュールにカスタマイズされたサービスの提供に焦点を当てることによってのみ、最小の依存関係関係を確立できます。
結束を改善し、外部の相互作用を減らします。インターフェイスの最小量を使用して、最も多くのことを達成します。
インターフェイス分離の原理を使用する場合、中程度でなければなりません。インターフェイス設計が大きすぎたり小さすぎたりすると良くありません。インターフェイスを設計するとき、より多くの時間を費やすことによってのみ、この原則を正確に実践できます。