인터페이스 분리 원칙, ISP 인터페이스 격리 원리는 여러 전용 인터페이스를 사용하는 것이 단일 총 인터페이스를 사용하는 것보다 낫다고 주장합니다.
다른 클래스에서 한 클래스의 의존성은 가장 작은 인터페이스에서 설정해야합니다.
인터페이스는 역할을 나타내며 다른 역할을 인터페이스로 넘겨서는 안됩니다. 관련없는 인터페이스는 함께 병합되어 부풀어 오른 큰 인터페이스를 형성하는데, 이는 역할과 인터페이스에 대한 오염입니다.
"고객은 사용하지 않는 방법에 의존해서는 안됩니다. 인터페이스는 클래스 계층 구조가 아니라 고객에게 속합니다." 이것은 매우 분명합니다. 간단히 말해서, 고객이 사용하지 않는 방법을 사용하도록 강요하지 마십시오. 사용자가 사용하지 않는 방법을 사용해야하는 경우이 고객은 사용하지 않는 이러한 방법의 변경으로 인해 변경 사항에 직면하게됩니다.
유스 케이스에서 발신자가 필요한 방법을 제공하고 불필요한 방법을 차단하십시오. 인터페이스 격리의 원리를 충족합니다. 예를 들어, 전자 상거래 시스템에는 주문 범주에 사용될 세 곳이 있습니다.
인터페이스 격리 원리 (ISP)에 따르면, 다른 클래스에서 한 클래스의 의존성은 가장 작은 인터페이스에서 설정되어야합니다.
즉, 포털의 경우 쿼리 메소드와의 인터페이스에만 의존 할 수 있습니다.
UML 구조는 다음과 같습니다.
인터페이스 격리의 원리를 무시하는 Java 인터페이스 쓰기의 예를 살펴 보겠습니다.
인터페이스 i {public void method1 (); 공개 무효 방법 2 (); 공개 무효 방법 3 (); 공개 무효 방법 4 (); 공개 무효 방법 5 (); } class a {public void eppend1 (i i) {i.method1 (); } public void eppend2 (i i) {i.method2 (); } public void fext3 (i i) {i.method3 (); }} 클래스 B는 i {public void method1 () {system.out.println ( "method1"을 인터페이스 i ");} public void method2 () {system.out.println ("클래스 B의 메소드 2 구현 인터페이스 i "); Method4와 Methods는 필요하지 않지만,이 두 가지 메소드의 방법 본문이 비어 있더라도,이 두 가지 메소드는 공개 void 방법을 구현해야한다. } public void eppend3 (i i) {i.method5 ()} 클래스 D 구현 i {public void method1 () {system.out.println (인터페이스 i를 구현하기위한 메소드 1 "); } // 클래스 D, Method2 및 Method3의 경우 필요하지 않지만 인터페이스 A에는이 두 가지 메소드가 있기 때문에 // 구현 프로세스 중에이 두 메소드의 메소드 본문이 비어 있더라도 효과가없는 두 가지 방법을 구현해야합니다. 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 = 새로운 C (); C.depend1 (new d ()); C.depend2 (New D ()); C.depend3 (New D ()); }} 인터페이스가 너무 부풀어 오르면 메소드가 인터페이스에 나타나는 한, 이에 의존하는 클래스에 유용한 지 여부에 관계없이 이러한 방법은 구현 클래스에서 구현되어야한다는 것을 알 수 있습니다. 이것은 분명히 좋은 디자인이 아닙니다. 이 설계가 인터페이스 격리의 원리를 준수하도록 수정되면 인터페이스가 분할되어야합니다. 여기서 원래 인터페이스 I을 3 개의 인터페이스로 나눕니다. 분할 설계는 다음 그림에 나와 있습니다.
평소와 같이, 클래스 다이어그램에 익숙하지 않은 친구들에 대한 참조를 위해 프로그램 코드를 게시하십시오.
인터페이스 i1 {public void method1 (); } 인터페이스 i2 {public void method2 (); 공개 무효 방법 3 (); } 인터페이스 i3 {public void method4 (); 공개 무효 방법 5 (); } class a {public void eppend1 (i1 i) {i.method1 (); } public void eppend2 (i2 i) {i.method2 (); } public void deppend3 (i2 i) {i.method3 (); }} 클래스 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 eppend1 (i1 i) {i.method1 (); } public void eppend2 (i3 i) {i.method4 (); } public void pection3 (i3 i) {i.method5 (); }} 클래스 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 개의 전용 인터페이스로 변경할 때 인터페이스 격리의 원리가 채택됩니다. 프로그래밍에서 여러 전용 인터페이스에 의존하는 것은 하나의 포괄적 인 인터페이스에 의존하는 것보다 유연합니다. 인터페이스는 설계 중에 외부 설정을 위해 "계약"설정입니다. 여러 인터페이스를 정의함으로써 외부 변화의 확산을 방지 할 수 있으며 시스템의 유연성과 유지 보수 가능성을 향상시킬 수 있습니다.
이에 대해 말하면, 많은 사람들은 인터페이스 격리의 원칙이 이전의 단일 책임 원칙과 매우 유사하다고 생각할 것입니다. 첫째, 단일 책임의 원칙은 책임에 중점을 둡니다. 인터페이스 격리의 원리는 인터페이스 의존성의 분리에 중점을 둡니다. 둘째, 단일 책임의 원칙은 주로 제약 클래스이며,이어서 프로그램의 구현 및 세부 사항을 목표로하는 인터페이스 및 방법이 뒤 따릅니다. 인터페이스 격리 원칙은 주로 인터페이스 인터페이스를 제한하고, 주로 추상화를 목표로하고, 전체 프로그램 프레임 워크의 구성을 목표로합니다.
인터페이스 격리 원칙을 사용하여 인터페이스를 제한 할 때 다음 지점은 다음에주의를 기울여야합니다.
인터페이스는 가능한 한 작아야하지만 제한적이어야합니다. 인터페이스를 개선하면 프로그래밍 유연성을 향상시킬 수 있다는 사실은 수익성이 없다는 사실이지만 너무 작 으면 인터페이스가 너무 많아서 설계를 복잡하게 만듭니다. 따라서 보통이어야합니다.
인터페이스에 의존하는 클래스에 대한 맞춤형 서비스, 호출 클래스에 노출되어야하는 메소드 및 필요한 방법 만 숨겨져 있습니다. 모듈에 맞춤형 서비스를 제공하는 데 중점을두면 최소 의존성 관계를 설정할 수 있습니다.
응집력을 향상시키고 외부 상호 작용을 줄입니다. 최소한의 인터페이스를 사용하여 가장 많은 것을 달성하십시오.
인터페이스 격리의 원리를 사용하는 경우 보통이어야합니다. 너무 크거나 작은 인터페이스 디자인을 갖는 것은 좋지 않습니다. 인터페이스를 설계 할 때는 더 많은 시간을 생각하고 계획하는 것만으로만이 원칙을 정확하게 연습 할 수 있습니다.