예:
void process(Consumer<Number> consumer);
다음으로 바꿔야 합니다.
void process(Consumer<? super Number> consumer);
이 메서드 시그니처는 더 많은 타입을 허용하므로 더 유연합니다(Consumer<Number>뿐만 아니라 Consumer<Object>도 허용).
마찬가지로, 공변성 위치에 있는 타입 매개변수도 허용합니다.
T produce(Producer<T> p);
다음으로 바꿔야 합니다.
T produce(Producer<? extends T> p);
Effective Java 3판에서 Joshua Bloch의 말을 인용하면 다음과 같습니다.
항목 31: 바운드된 와일드카드를 사용하여 API 유연성 향상
까다롭기는 하지만, API에서 와일드카드 타입을 사용하면 API의 유연성이 훨씬 더 높아집니다. 광범위하게 사용될 라이브러리를 작성하는 경우, 와일드카드 타입의 적절한 사용을 반드시 고려해야 합니다. 프로듀서-extends, 컨슈머-super(PECS)라는 기본 규칙을 기억하세요. 또한 모든 Comparable 및 Comparator가 컨슈머인 것도 기억하세요.
보고 대상을 전환하려면 검사 옵션을 사용하세요.
무공변성 클래스. 예를 들어, 무공변성 클래스는 값을 허용(List.add(T) 메서드를 통해)할 뿐만 아니라 생성(T List.get() 메서드를 통해)하기도 하기 때문에 java.util.List<T>입니다.
한편, contravariant 클래스는 값을 받기만 합니다. 예를 들어, 유일한 메서드 accept(T)가 포함된 java.util.function.Consumer<T>가 이에 해당합니다. 유사하게, covariant 클래스는 값을 생성하기만 합니다. 예를 들어, 유일한 메서드T get()이 포함된 java.util.function.Supplier<T>가 이에 해당합니다.
보통 공변성/반공변성 클래스에서는 바운드된 와일드카드가 종종 사용되지만 무공변성 클래스(예: void process(List<? extends T> l))에서는 지양됩니다.
이러한 무공변성 클래스를 무시하고 void process(List<T> l) 같은 엄격한 타입을 유지하려면 이 옵션을 비활성화합니다.
private 메서드. 이 메서드는 public API의 일부가 아닌 것으로 간주될 수 있습니다.
인스턴스 메서드