정의 : 클라이언트는 필요하지 않은 인터페이스에 의존해서는 안됩니다. 한 클래스의 다른 클래스의 의존성은 가장 작은 인터페이스에서 설정해야합니다.
문제는 다음과 같습니다. 클래스 A는 인터페이스 i를 통한 클래스 B에 의존하고 클래스 C는 인터페이스 I을 통해 클래스 D에 의존합니다. 인터페이스 I가 클래스 A 및 클래스 B의 가장 작은 인터페이스가 아닌 경우 클래스 B와 클래스 D는 필요하지 않은 메소드를 구현해야합니다.
솔루션 : 부풀린 인터페이스 I을 여러 독립 인터페이스로 나누고 클래스 A와 클래스 C는 각각 필요한 인터페이스와 의존성을 설정합니다. 즉, 인터페이스 격리의 원리가 채택됩니다.
인터페이스 격리의 원리를 설명하기위한 예를 들어 봅시다.
이 그림의 의미는 다음과 같습니다. 클래스 A는 메소드 1, 메소드 2, 메소드 3의 계면 I에 의존하며 클래스 B는 클래스 A에 의존성의 구현입니다. 클래스 C는 계면 I의 메소드 1, 메소드 4, 메소드 5 및 클래스 D에 의존하는데 클래스 B 및 D에 대한 의존성의 구현은 사용되지 않은 방법을 가지고 있지만 (즉, 수치에서 구현되어야하기 때문에), 이들은 구현되어야하지만, 이들은 구현되어야한다.
먼저 인터페이스 격리 위반의 예를 살펴 보겠습니다.
공개 인터페이스 iWorker {public void Work (); 공공 공간 eat (); } 공공 계급 노동자는 iWorker {@Override public void Work () {// todo Worker Work} @Override public void eat () {// todo worker eat}} 공개 클래스 로봇을 구현합니다. @override public void work () {// todo robot void eat () {// eat? }}
로봇은 먹을 필요가 없기 때문에 iWorker는 부풀어 오른 인터페이스로 간주됩니다. 물론 로봇 클래스에서 EAT 메소드의 단기 구현도 할 수 있지만 이로 인해 예측할 수없는 버그가 발생할 수 있습니다. 예를 들어, Eat Method가 도시락 수를 소비 해야하는 경우 잘못된 현상이 발생합니다.
다음은 수정 된 구현입니다.
공개 인터페이스 iWorker {public void Work (); } public interface idiet {public void eat (); } 공공 클래스 노동자는 iWorker, idiet {@override public void work () {// todo work} @override public void eat () {// todo work}} 공개 클래스 로봇을 구현합니다 {@override public void work () {// todo robot work}}
요약 :
1. 인터페이스는 가능한 작고 응집력이 뛰어나야하지만 적절하고 너무 상세하며 유지하기가 어렵습니다.
2. 부풀린 인터페이스로 설계된 경우 어댑터 모드를 사용하여 분리 할 수 있습니다.