nên thay vì vì E là so sánh, con cái của E phải so sánh được trong khi bố mẹ của E có thể không.
Comparator không phụ thuộc vào các đối tượng Comparable.
Nó thậm chí thường được sử dụng như là một thay thế hoặc bổ sung.
Trong thực tế, constructor này
public TreeSet(Comparator<? super E> comparator) {...}
có thể là:
public TreeSet(Comparator<E> comparator) {... }
Nhưng bằng cách xác định một kí hiệu wildcard bao thấp hơn, các nhà phát triển JDK cung cấp linh hoạt hơn cho các lớp khách hàng bằng cách cho phép các Comparator được tương thích với cả các cá thể lớp hiện tại và các cá thể lớp cha. Trong một số trường hợp, nó có thể có ý nghĩa.
Bây giờ này:
public TreeSet(Comparator<? extend E> comparator) {
không thể có giá trị vì nó có nghĩa là bạn có thể kết thúc với một phương pháp compare() mà xác định loại lớp con như thông số.
Nhưng các phần tử của Set có thể chứa các phiên bản của một phân lớp cụ thể nhưng không chỉ.
Imagine mã này:
TreeSet<CharSequence> set = new TreeSet<>(new Comparator<String>() {
@Override
public int compare(String o1, String o2) {
...
}
});
set.add("string");
set.add(new StringBuilder());
...
Tôi muốn so sánh String s nhưng Set có thể chứa String trường mà còn bất kỳ lớp con của CharSequence như StringBuilder, CharBuffer, vv ...
Và nếu CharSequence là không phải là abstract, nó cũng có thể chứa các phiên bản của chúng.
Với ví dụ này, chúng tôi hiểu rằng khái niệm Comparator<? extend E> là sai.