인터페이스에서 "선택적 메소드"로 Java 콜렉션이 구현 된 이유는 무엇입니까?

Java 콜렉션 프레임 워크를 확장 한 첫 번째 구현 중에 콜렉션 인터페이스에 선택적으로 선언 된 메소드가 포함되어 있다는 사실에 놀랐습니다. 구현되지 않은 경우 구현자는 UnsupportedOperationExceptions를 발생시킵니다. 이것은 즉시 API 디자인 선택이 좋지 않은 것으로 나타났습니다.

Joshua Bloch의 뛰어난 "Effective Java"책을 많이 읽은 후 나중에 이러한 결정에 대한 책임을진다는 사실을 알게 된 후에는이 책에 포함 된 원칙을 따르지 않는 것 같습니다. "선택적"메소드로 Collection을 확장하는 Collection과 MutableCollection이라는 두 가지 인터페이스를 선언하면 훨씬 더 유지 관리 가능한 클라이언트 코드가 생겼을 것입니다.

여기 에 문제에 대한 훌륭한 요약이 있습니다 .

두 개의 인터페이스 구현 대신에 선택적 메소드를 선택한 이유가 있습니까?

질문은 답을 제공합니다. 요컨대, 그들은 가능한 각 구현 옵션 옵션 세트에 대해 수정 가능하고 수정 불가능한보기, 삭제 전용, 추가 전용, 고정 길이, 불변 (스레딩에 대한) 등으로 필요한 인터페이스의 조합 조합 폭발을 목격했습니다.

그것은 지금처럼 Interface Segregation Principle잘 탐험되지 않았던 것처럼 들린다 . SOLID와 ISP가 품질 코드의 사실상의 표준이되기 전에는 이러한 방식의 작업 (즉, 인터페이스에 가능한 모든 작업이 포함되어 있고 필요하지 않은 예외에 대해 예외를 발생시키는 "축소 된"메소드가 있음)이 사용되었습니다.

어떤 사람들은 "선택적 방법"을 싫어할 수 있지만, 많은 경우 고도로 분리 된 인터페이스보다 더 나은 의미를 제공 할 수 있습니다. 무엇보다, 그들은 객체가 일생 동안 능력이나 특성을 얻을 수 있거나, 객체 (특히 래퍼 객체)가 언제 어떤 정확한 능력을보고해야하는지 알 수없는 가능성을 허용합니다.

좋은 디자인의 Java 콜렉션 클래스 모범 (paragon)이라고 부르지는 않지만, 훌륭한 콜렉션 프레임 워크는 그 특성과 능력에 대한 콜렉션을 요청하는 방법 과 함께 많은 선택적 메소드 를 기본으로 포함해야한다고 제안 합니다 . 이러한 디자인은 단일 래퍼 클래스가 기본 컬렉션이 보유 할 수있는 능력을 실수로 모호하게하지 않으면 서 다양한 컬렉션과 함께 사용할 수 있도록합니다. 메소드가 선택 사항이 아닌 경우 콜렉션이 지원할 수있는 모든 기능 조합에 대해 다른 랩퍼 클래스가 필요하거나 일부 상황에서 일부 랩퍼를 사용할 수 없게해야합니다.

예를 들어, 컬렉션이 인덱스로 항목을 쓰거나 끝에 항목을 추가 할 수는 있지만 중간에 항목을 삽입하는 것을 지원하지 않는 경우에는 래퍼로 항목을 캡슐화하려는 코드에서 실행되는 모든 작업을 기록하는 코드가 버전이 필요합니다 지원되는 기능의 정확한 조합을 제공하는 로깅 래퍼의 경우 또는 사용 가능한 것이없는 경우 추가 또는 색인 별 쓰기를 지원하지만 둘 다를 지원하지 않는 래퍼를 사용해야합니다. 그러나 통합 콜렉션 인터페이스가 세 가지 메소드를 모두 "선택적"으로 제공했지만 사용할 수있는 선택적 메소드를 표시하는 메소드를 포함하면 단일 랩퍼 클래스가 기능 조합을 구현하는 콜렉션을 처리 할 수 ​​있습니다. 지원하는 기능이 무엇인지 물으면 랩퍼는 캡슐화 된 콜렉션이 지원하는 모든 것을 간단히보고 할 수 있습니다.

"선택적 능력"의 존재는 어떤 경우에는 집합의 콜렉션이 구현의 존재에 의해 능력이 정의 된 경우 가능한 것보다 훨씬 더 효율적인 방식으로 특정 기능을 구현할 수있게한다. 예를 들어, concatenate메소드가 두 개의 다른 콜렉션 중에서 복합 콜렉션을 형성하는 데 사용되었다고 가정 하십시오. 첫 번째는 1,000,000 개의 요소가있는 ArrayList이고 마지막은 시작부터 반복 할 수있는 20 개의 요소 콜렉션이었습니다. 복합 컬렉션에 1,000,013 번째 요소 (인덱스 1,000,012)가 요청 된 경우 ArrayList에 포함 된 항목 수 (예 : 1,000,000)를 요청하고 요청 된 인덱스에서 해당 항목을 빼고 (수율 12) 두 번째 요소에서 12 개의 요소를 읽고 건너 뛸 수 있습니다. 컬렉션, 다음 요소를 반환합니다.

이러한 상황에서 복합 콜렉션은 인덱스로 항목을 즉시 리턴하는 방법이 없지만 1,000,013 번째 항목에 대해 복합 콜렉션을 요청하는 것은 개별적으로 1,000,013 개의 항목을 읽고 마지막을 제외한 모든 항목을 무시하는 것보다 훨씬 빠릅니다. 하나.

나는 당시에 더 잘 알지 못했던 원래 개발자에게 귀속되었습니다. Java 2 및 Collections가 처음 릴리스 된 1998 년 이후 OO 디자인에서 먼 길을 왔습니다. 명백한 나쁜 디자인처럼 보이는 것은 OOP 초기에 그렇게 명확하지 않았습니다.

그러나 추가 캐스팅을 방지하기 위해 수행되었을 수 있습니다. 두 번째 인터페이스라면 컬렉션 인스턴스를 캐스팅하여 추악한 옵션 메소드를 호출해야합니다. 이제 UnsupportedOperationException을 즉시 포착하고 코드를 수정합니다. 그러나 두 개의 인터페이스가 있다면 instanceof와 cast를 사용해야합니다. 아마도 그들은 유효한 상충 관계라고 생각했을 것입니다. 또한 초기 Java 2 일에 인스턴스의 성능이 느리기 때문에 심한 인상을 받았고, 과잉 사용을 방지하려고 시도했을 수도 있습니다.

물론 이것은 모두 사색적인 추측입니다. 원래 컬렉션 건축가 중 하나가 차임하지 않는 한 확실히 대답 할 수는 없습니다.