[java] Java 인터페이스의 선택적 메소드

여기에 대한 답변에 끔찍한 혼란이있는 것 같습니다.

Java 언어에서는 인터페이스의 모든 메소드가 해당 인터페이스의 모든 구현에 의해 구현되어야합니다. 기간. 이 규칙에는 예외가 없습니다. “컬렉션은 예외입니다”라는 말은 여기서 실제로 일어나는 일에 대한 매우 모호한 이해를 의미합니다.

인터페이스를 준수하는 데는 두 가지 수준이 있다는 것을 인식하는 것이 중요합니다.

1. Java 언어로 확인할 수있는 항목. 이것은 꽤 많은 단지로 귀결이 어떤 방법 각각에 대한 구현은?

2. 실제로 계약을 이행했습니다. 즉, 구현이 인터페이스의 문서에 명시된대로 수행합니까?

   잘 작성된 인터페이스에는 구현에서 예상되는 것을 정확히 설명하는 문서가 포함됩니다. 컴파일러는 이것을 확인할 수 없습니다. 문서를 읽고 그들이 말하는대로해야합니다. 계약서에 명시된대로 수행하지 않으면 컴파일러 에 관한 한 인터페이스 구현 이 가능하지만 결함 / 잘못된 구현이됩니다.

컬렉션 API를 디자인 할 때 Joshua Bloch는 컬렉션의 다양한 변형 (예 : 읽기 가능, 쓰기 가능, 임의 액세스 등)을 구별하기 위해 매우 세밀한 인터페이스를 사용하는 대신 매우 조잡한 인터페이스 세트 만 사용하기로 결정했습니다.
Collection, List, Set그리고 Map다음 “선택”과 같은 특정 작업을 문서화합니다. 이는 세분화 된 인터페이스로 인해 발생할 수있는 조합 적 폭발을 방지하기위한 것입니다. 로부터 자바 컬렉션 API 디자인 자주 묻는 질문 :

문제를 자세히 설명하기 위해 계층 구조에 수정 가능성 개념을 추가한다고 가정합니다. ModifiableCollection, ModifiableSet, ModifiableList 및 ModifiableMap의 네 가지 새 인터페이스가 필요합니다. 이전에 단순한 계층이었던 것이 이제는 지저분한 계층이되었습니다. 또한 제거 작업을 포함하지 않는 수정 불가능한 컬렉션과 함께 사용할 새 Iterator 인터페이스가 필요합니다. 이제 UnsupportedOperationException을 제거 할 수 있습니까? 불행히도.

배열을 고려하십시오. 대부분의 List 작업을 구현하지만 제거 및 추가는 수행하지 않습니다. 그들은 “고정 크기”목록입니다. 계층 구조에서이 개념을 캡처하려면 VariableSizeList 및 VariableSizeMap이라는 두 개의 새 인터페이스를 추가해야합니다. VariableSizeCollection 및 VariableSizeSet은 ModifiableCollection 및 ModifiableSet과 동일하므로 추가 할 필요가 없지만 일관성을 위해 추가하도록 선택할 수 있습니다. 또한 수정 불가능한 List와 함께 이동하려면 추가 및 제거 작업을 지원하지 않는 새로운 다양한 ListIterator가 필요합니다. 이제 우리는 원래 4 개 대신 최대 10 개 또는 12 개의 인터페이스와 2 개의 새로운 Iterator 인터페이스가 있습니다. 끝났어? 아니.

로그 (예 : 복구 가능한 데이터 개체에 대한 오류 로그, 감사 로그 및 저널)를 고려합니다. 제거 및 설정 (바꾸기)을 제외한 모든 List 작업을 지원하는 자연스러운 추가 전용 시퀀스입니다. 새로운 핵심 인터페이스와 새로운 반복자가 필요합니다.

그리고 수정 불가능한 콜렉션과 달리 불변의 콜렉션은 어떻습니까? (즉, 클라이언트가 변경할 수없고 다른 이유로 변경되지 않는 컬렉션). 많은 스레드가 동기화없이 컬렉션에 동시에 액세스 할 수 있기 때문에 이것이 가장 중요한 차이점이라고 주장합니다. 이 지원을 유형 계층 구조에 추가하려면 인터페이스가 4 개 더 필요합니다.

이제 우리는 최대 20 개 정도의 인터페이스와 5 개의 반복자이며, 실제로 어떤 인터페이스에도 깔끔하게 맞지 않는 컬렉션이 실제로 발생하는 것이 거의 확실합니다. 예를 들어 Map에서 반환하는 컬렉션 뷰는 자연적인 삭제 전용 컬렉션입니다. 또한 값을 기준으로 특정 요소를 거부하는 컬렉션이 있으므로 런타임 예외를 처리하지 않았습니다.

모든 것을 말하고 완료했을 때, 우리는 런타임 예외를 던질 수있는 매우 작은 핵심 인터페이스 세트를 제공함으로써 전체 문제를 회피하는 것이 건전한 엔지니어링 타협이라고 느꼈습니다.

Collections API의 메서드가 “선택적 작업”으로 문서화되어 있다고해서 메서드 구현을 구현에서 제외 할 수 있다는 의미도 아니며 빈 메서드 본문을 사용할 수 있다는 의미도 아닙니다. 결과를 반환해야합니다). 오히려 유효한 구현 선택 (여전히 계약을 준수하는)은 UnsupportedOperationException.

그 때문에 참고 UnsupportedOperationExceptionA는 RuntimeException당신이 멀리 컴파일러에 관한 한, 어떤 메소드 구현에서 던질 수 있습니다. 예를 들어, Collection.size(). 그러나 이러한 구현은 문서에 Collection.size()이것이 허용된다고 명시 되어 있지 않으므로 계약을 위반하게 됩니다.

곁에 : Java의 Collections API가 사용하는 접근 방식은 다소 논란의 여지가 있습니다 (하지만 처음 도입되었을 때보 다 지금은 적을 것입니다). 완벽한 세상에서는 인터페이스에 선택적 작업 이 없으며 대신 세분화 된 인터페이스가 사용됩니다. 문제는 Java가 유추 된 구조 유형이나 교차 유형을 지원하지 않는다는 것입니다. 이것이 바로 컬렉션의 경우 “올바른 방법”으로 작업을 시도하는 것이 극도로 다루기 힘들어지는 이유입니다.

답변

interface Foo {
  void doSomething();
  void doSomethingElse();
}

class MyClass implements Foo {
  public void doSomething() {
     /* All of my code goes here */
  }

  public void doSomethingElse() {
    // I leave this unimplemented
  }
}

class SubClass extends MyClass {
    @Override
    public void doSomethingElse() {
      // Here's my implementation. 
    }
}

public class Foo {
    public interface Callback {
        public void requiredMethod1();
        public void requiredMethod2();
    }

    public interface CallbackExtended extends Callback {
        public void optionalMethod1();
        public void optionalMethod2();
    }

    private Callback mCallback;
}

public SomeReturnType optionalInterfaceMethodA(...) {
    throw new UnsupportedOperationException();
}

public interface List<E> {
    :
    :
    default public boolean add(E element) {
        throw new UnsupportedOperationException();
    }
    :
    :
}