Java 컬렉션 프레임 워크 인터페이스에서 UnsupportedOperationException

Java Collections Framework를 살펴보면 인터페이스 중 일부에 주석이 있음을 알았습니다 (optional operation). 이러한 메소드를 사용 UnsupportedOperationException하면 해당 메소드를 구현하지 않으려 는 경우 클래스를 통해 구현할 수 있습니다.

이에 대한 예는의 addAll방법입니다 Set Interface.

이제이 일련의 질문에서 언급했듯이 인터페이스는 용도에 대한 정의 계약입니다.

인터페이스는 클래스의 기능과 클래스의 기능을 분리하기 때문에 중요합니다. 고객이 기대할 수있는 것을 정의하는 계약은 개발자가 계약을지지하는 한 원하는 방식으로 자유롭게 구현할 수 있도록합니다.

과

인터페이스는 객체가 수행 할 수있는 동작에 대한 설명입니다. 예를 들어 전등 스위치를 뒤집거나 전등이 켜질 때 어떻게되는지 신경 쓰지 않아도됩니다. 객체 지향 프로그래밍에서 인터페이스는 객체가 "X"가되기 위해 가져야하는 모든 기능에 대한 설명입니다.

과

인터페이스 기반 접근 방식이 훨씬 훌륭하다고 생각합니다. 그런 다음 의존성을 멋지게 조롱 할 수 있으며 모든 것이 기본적으로 덜 밀접하게 결합됩니다.

인터페이스의 요점은 무엇입니까?

인터페이스 란 무엇입니까?

인터페이스 + 확장 (믹싱) vs 기본 클래스

인터페이스의 목적은 계약을 정의하고 종속성을 느슨하게 결합 UnsupportedOperationException하는 것이므로 일부 방법으로 목적을 달성 하지 못 합니까? 더 이상 통과 할 수 없으며 Set그냥 사용할 수 있음을 의미 합니다 addAll. 오히려 어떤 구현 Set이 전달되었는지 알아야하므로 사용할 수 있는지 여부를 알 수 있습니다 addAll. 그건 나에게 쓸모없는 것 같습니다.

그래서 요점은 UnsupportedOperationException무엇입니까? 레거시 코드를 보완하고 인터페이스를 정리해야합니까? 아니면 내가 놓친 더 감각적 인 목적이 있습니까?

다음 인터페이스를보십시오.

• 수집
• 명부
• 지도
• 세트

이 인터페이스는 모두 변경 메소드 를 선택 사항으로 선언 합니다. 이것은 Collections 클래스가 불변 인 인터페이스의 구현을 리턴 할 수 있다는 사실을 암시 적으로 문서화하고 있습니다. 그러나 JavaDoc의 계약에 따라 해당 인터페이스의 모든 구현은 읽기 조작을 허용해야합니다. 이 같은 "정상"구현을 포함 HashSet하고 LinkedList뿐만 아니라의 불변 포장기 Collections.

대기열 인터페이스와 대조 :

• 데크
• 열

이러한 인터페이스는 선택적 작업을 지정 하지 않습니다 . 큐는 정의에 따라 FIFO 방식으로 요소를 제공하고 폴링하도록 설계되었습니다. 불변 큐는 바퀴가없는 자동차만큼이나 유용합니다.

반복적으로 나타나는 한 가지 일반적인 아이디어는 변경 가능하고 변경 불가능한 객체를 모두 갖는 상속 계층 구조를 갖는 것입니다. 그러나 이러한 모든 단점이 있습니다. 복잡성은 실제로 문제를 해결하지 않고 물을 흐릿하게 만듭니다.

• 가상의 Set경우 읽기 작업이 가능하고 하위 인터페이스 MutableSet에는 쓰기 작업이있을 수 있습니다. Liskov 는 a MutableSet가 필요한 모든 것에 전달 될 수 있다고 말합니다 Set. 처음에는 괜찮은 것처럼 들리지만, 읽는 동안 기본 세트가 수정되지 않을 것으로 예상되는 방법을 고려하십시오. 두 스레드가 동일한 세트를 사용하고 변경되지 않는 세트의 불변을 위반할 수 있습니다. 예를 들어 메소드가 세트에서 요소를 두 번 읽고 처음에는 있지만 두 번째에는없는 경우 문제가 발생할 수 있습니다.

• Set대신 갖는 직접적인 구현이 없었다 MutableSet및 ImmutableSet다음 클래스를 구현하기 위해 사용되는 서브한다. 위와 같은 문제가 있습니다. 계층의 어느 시점에서 인터페이스에 불변이 있습니다. 하나는 "이 세트는 변경 가능해야합니다"라고 말하고 다른 하나는 "이 세트는 변경할 수 없습니다"라고 말합니다.

• 변경 가능하고 변경 불가능한 데이터 구조에 대해 완전히 별개의 계층이 두 개있을 수 있습니다. 이것은 추가 톤 약간의 이득이 될 수있을 테니까요 어떤 여분의 복잡성을. 이것은 또한 변경 가능성에 신경 쓰지 않는 메소드의 특정 약점을 가지고 있습니다 (예 : 목록을 반복하고 싶습니다)는 이제 두 개의 별도 인터페이스를 지원해야합니다. Java는 정적으로 유형이 지정되므로 두 인터페이스 계층을 모두 처리하는 추가 방법을 의미합니다.

• 단일 인터페이스를 가질 수 있고 메소드가 적용 가능하지 않은 경우 구현에서 예외를 발생시킬 수 있습니다. 이것이 Java가 취한 경로이며 가장 의미가 있습니다. 인터페이스의 수는 최소로 유지되며 문서화 된 인터페이스는 어느 쪽이든 변경 가능성을 보장 하지 않으므로 변경 불변성이 없습니다 . 불변 불변성이 필요한 경우의 래퍼를 사용하십시오 Collections. 메소드가 콜렉션을 변경할 필요가 없으면 단순히 변경하지 마십시오. 단점은 외부에서 컬렉션이 제공되는 경우 컬렉션이 다른 스레드에서 변경되지 않도록 보장 할 수 없지만 어쨌든 호출 방법 (또는 호출 방법)의 문제입니다.

관련 독서 : 왜 Java 8에 불변 컬렉션이 포함되지 않습니까?

기본적으로 YAGNI입니다. 표준 라이브러리의 모든 구체적인 컬렉션은 변경 가능하며 선택적 작업을 구현하거나 상속합니다. 범용 불변 콜렉션에 신경 쓰지 않으며 대다수의 Java 개발자도 마찬가지입니다. 변경 불가능한 콜렉션에 대해서만 전체 인터페이스 계층을 작성하지 않으며 구현을 포함하지 않습니다.

한편, empty set 및 nCopies 와 같이 불변으로 매우 유용 할 수있는 몇 가지 특수 목적의 값 또는 "가상"콜렉션이 있습니다 . 또한 기존 Java 코드를 호출하려는 타사 불변 콜렉션 (예 : 스칼라)이 있으므로 불변 콜렉션이 최소한의 방해로 열릴 가능성이 있습니다.