이 글은 주로 인터페이스 격리의 원리를 소개합니다. 편집자는 이것이 꽤 좋다고 생각합니다. 이제 공유하고 참고용으로 제공하겠습니다. 편집기를 따라 살펴보겠습니다
정의: 클라이언트는 필요하지 않은 인터페이스에 의존해서는 안 됩니다. 한 클래스가 다른 클래스에 의존하는 것은 가장 작은 인터페이스를 기반으로 해야 합니다.
문제의 원인: 클래스 A는 인터페이스 I을 통해 클래스 B에 종속되고 클래스 C는 인터페이스 I을 통해 클래스 D에 종속됩니다. 인터페이스 I가 클래스 A와 클래스 B에 대한 최소 인터페이스가 아닌 경우 클래스 B와 클래스 D는 이를 구현해야 합니다.
해결책: 비대해진 인터페이스 I를 여러 개의 독립적인 인터페이스로 분할하고 클래스 A와 클래스 C는 각각 필요한 인터페이스와의 종속성을 설정합니다. 즉, 인터페이스 격리 원칙이 채택됩니다.
인터페이스 격리 원칙을 설명하는 예:
(그림 1 인터페이스 격리 원칙을 따르지 않는 설계)
이 그림의 의미: 클래스 A는 인터페이스 I의 메서드 1, 메서드 2, 메서드 3에 종속됩니다. , 클래스 B는 클래스 A에 대한 종속성의 구현입니다. 클래스 C는 인터페이스 I의 메서드 1, 메서드 4, 메서드 5에 의존합니다. 클래스 D는 클래스 C에 대한 종속성을 구현합니다. 클래스 B와 D의 경우 둘 다 사용되지 않는 메소드(즉, 그림에서 빨간색으로 표시된 메소드)가 있지만 인터페이스 I이 구현되어 있으므로 이러한 사용되지 않는 메소드도 구현해야 합니다. 클래스 다이어그램에 익숙하지 않은 분들은 프로그램 코드를 참고하시면 이해하실 수 있습니다. 코드는 다음과 같습니다.
interface 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 depend2(I i){ i.method2(); } public void depend3(I i){ i.method3(); } } class B implements I{ public void method1() { System.out.println("类B实现接口I的方法1"); } public void method2() { System.out.println("类B实现接口I的方法2"); } public void method3() { System.out.println("类B实现接口I的方法3"); } //对于类B来说,method4和method5不是必需的,但是由于接口A中有这两个方法, //所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。 public void method4() {} public void method5() {} } class C{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method4(); } public void depend3(I i){ i.method5(); } } class D implements I{ public void method1() { System.out.println("类D实现接口I的方法1"); } //对于类D来说,method2和method3不是必需的,但是由于接口A中有这两个方法, //所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。 public void method2() {} public void method3() {} public void method4() { System.out.println("类D实现接口I的方法4"); } public void method5() { System.out.println("类D实现接口I的方法5"); } } 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를 세 개의 인터페이스로 분할합니다. 분할 설계는 그림 2에 나와 있습니다.
(그림 2 인터페이스 격리 원칙에 따른 설계)
친구가 참조할 수 있도록 평소대로 프로그램 게시 클래스 다이어그램에 익숙하지 않은 경우:
interface 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 depend2(I2 i){ i.method2(); } public void depend3(I2 i){ i.method3(); } } class B implements I1, I2{ public void method1() { System.out.println("类B实现接口I1的方法1"); } public void method2() { System.out.println("类B实现接口I2的方法2"); } public void method3() { System.out.println("类B实现接口I2的方法3"); } } class C{ public void depend1(I1 i){ i.method1(); } public void depend2(I3 i){ i.method4(); } public void depend3(I3 i){ i.method5(); } } class D implements I1, I3{ public void method1() { System.out.println("类D实现接口I1的方法1"); } public void method4() { System.out.println("类D实现接口I3的方法4"); } public void method5() { System.out.println("类D实现接口I3的方法5"); } }
인터페이스 격리 원칙의 의미는 다음과 같습니다. 단일 인터페이스를 설정하고, 거대하고 비대해진 인터페이스를 구축하지 말고, 인터페이스를 최대한 개선하려고 노력하고, 최대한 인터페이스에는 가능한 한 몇 가지 메소드가 있습니다. 즉, 호출에 의존하는 모든 클래스에 대해 거대한 인터페이스를 구축하려고 하기보다는 각 클래스에 대한 전용 인터페이스를 구축해야 합니다. 이 기사의 예에서는 인터페이스 격리 원칙을 사용하여 거대한 인터페이스를 세 개의 전용 인터페이스로 변경합니다. 프로그래밍에서는 하나의 포괄적인 인터페이스에 의존하는 것보다 여러 전용 인터페이스에 의존하는 것이 더 유연합니다. 인터페이스는 설계 과정에서 외부적으로 설정된 "계약"입니다. 여러 인터페이스를 분산적으로 정의함으로써 외부 변경 사항의 확산을 방지하고 시스템의 유연성과 유지 관리성을 향상시킬 수 있습니다.
이렇게 말하면 많은 사람들이 인터페이스 격리 원칙이 이전 단일 책임 원칙과 매우 유사하다고 생각하지만 그렇지 않습니다. 첫째, 단일 책임 원칙은 원래 책임에 중점을 두었지만 인터페이스 격리 원칙은 인터페이스 종속성 격리에 중점을 두었습니다. 둘째, 단일 책임 원칙은 주로 클래스를 제한하고 그 다음에는 프로그램의 구현과 세부 사항을 목표로 하는 인터페이스와 메서드를 제한하는 반면, 인터페이스 격리 원칙은 주로 추상화와 프로그램의 전체 프레임워크 구성을 위해 인터페이스를 제한합니다. .
인터페이스 격리 원칙을 사용하여 인터페이스를 제한하는 경우 다음 사항에 주의하세요.
인터페이스는 최대한 작아야 하지만 제한 내에 있어야 합니다. 인터페이스를 개선하면 프로그래밍 유연성을 높일 수 있다는 것은 사실이지만 너무 작으면 인터페이스가 너무 많아지고 디자인이 복잡해집니다. 그러므로 적당히 이루어져야합니다.
인터페이스에 의존하는 클래스에 대한 서비스를 사용자 정의하고, 호출 클래스에 필요한 메서드만 노출하고, 필요하지 않은 메서드는 숨깁니다. 모듈에 대한 맞춤형 서비스 제공에 집중해야만 종속성을 최소화할 수 있습니다.
결속력을 향상하고 외부 상호 작용을 줄입니다. 인터페이스에서 가장 적은 메서드를 사용하여 가장 많은 작업을 수행하도록 합니다.
인터페이스 격리 원칙을 준수해야 하며 인터페이스를 너무 크거나 작게 디자인하는 것은 좋지 않습니다. 인터페이스를 디자인할 때 생각하고 계획하는 데 더 많은 시간을 투자해야만 이 원칙을 정확하게 구현할 수 있습니다
위 내용은 Java의 인터페이스 격리 원칙에 대한 설명 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!