Java SortedSet + Comparator, вопрос согласованности с equals()

Как написал ChssPly76 в комментарии, вы можете использовать hashCode для определения вызова compareTo в случае, когда две коллекции имеют одинаковый размер, но не равны. Это работает нормально, за исключением редкого случая, когда у вас есть две коллекции одинакового размера, которые не равны, но имеют одинаковый хэш-код. Правда, шансы на это довольно малы, но вполне допустимы. Если вы хотите быть очень осторожным, вместо hashCode используйте System.identityHashCode. Это должно дать вам уникальный номер для каждой коллекции, и у вас не должно быть коллизий.

В конце концов, это дает вам функциональность сортировки коллекций в наборе по размеру с произвольным порядком в случае двух коллекций с одинаковым размером. Если это все, что вам нужно, это не намного медленнее, чем обычное сравнение. Если вам нужно, чтобы порядок был согласован между разными экземплярами JVM, это не сработает, и вам придется сделать это каким-то другим способом.

псевдокод:

if (a.equals(b)) {
    return 0;
} else if (a.size() > b.size()) {
    return 1;
} else if (b.size() > a.size()) {
    return -1;
} else {
    return System.identityHashCode(a) > System.identityHashCode(b) ? 1 : -1;
}

Интерфейс SortedSet расширяет ядро ​​Set и, следовательно, должен соответствовать контракту указано в спецификации Set.

Единственный возможный способ добиться этого — сделать так, чтобы поведение метода equal() вашего элемента соответствовало вашему Comparator — причина этого в том, что ядро ​​Set работает на основе равенства, тогда как SortedSet работает на основе сравнения.

Например, add()< Метод /a>, определенный в базовом интерфейсе Set, указывает, что вы не можете добавить элемент в набор, если уже есть элемент, чей метод equal() вернет true с этим новым элементом в качестве аргумента. Ну, SortedSet не использует equal(), он использует compareTo(). Поэтому, если ваш compareTo() возвращает false, ваш элемент БУДЕТ добавлен, даже если equals() должен был вернуть true, тем самым нарушая контракт Set.

Кажется, это нарушает запрет на то, чтобы Comparator был совместим с equals() - т. Е. Две коллекции могут быть неравными (имея разные элементы), но сравниваться с одним и тем же значением (потому что они имеют одинаковое количество элементов).

Нет требований, заявленных (в Javadoc) или подразумеваемых, чтобы Comparator соответствовал реализации объекта boolean equals(Object).

Обратите внимание, что Comparable и Comparator — это разные интерфейсы с разными целями. Comparable используется для определения «естественного» порядка для класса. В этом контексте было бы плохой идеей, если бы equals и compateTo были несовместимы. Напротив, Comparator используется, когда вы хотите использовать порядок, отличный от естественного порядка класса.

РЕДАКТИРОВАТЬ: Вот полный абзац из Javadoc для SortedSet.

Обратите внимание, что порядок, поддерживаемый отсортированным набором (независимо от того, предоставлен явный компаратор или нет), должен соответствовать равенству, если отсортированный набор должен правильно реализовать интерфейс Set. (См. интерфейс Comparable или интерфейс Comparator для точного определения соответствия с равными.) Это так, потому что интерфейс Set определен в терминах операции равенства, но отсортированный набор выполняет все сравнения элементов, используя свой метод compareTo (или сравнение). , так что два элемента, которые считаются равными с помощью этого метода, равны с точки зрения отсортированного множества. Поведение отсортированного набора четко определено, даже если его порядок несовместим с равными; он просто не подчиняется общему контракту интерфейса Set.

Я выделил последнюю фразу. Дело в том, что такой SortedSet будет работать так, как вы, скорее всего, ожидаете, но поведение некоторых операций не будет точно соответствовать спецификации Set... потому что спецификация определяет их поведение в терминах метода equals.

Так что на самом деле существует существует заявленное требование согласованности (моя ошибка), но последствия его игнорирования не так ужасны, как вы могли бы подумать. Конечно, вам решать, стоит ли вам это делать. По моей оценке, все должно быть в порядке, если вы тщательно прокомментируете код и убедитесь, что SortedSet не «утекает».

Однако мне не ясно, будет ли компаратор для коллекций, который смотрит только на «размер» коллекций, работать ... с семантической точки зрения. Я имею в виду, вы действительно хотите сказать, что все коллекции с (скажем) 2 элементами равны? Это будет означать, что ваш набор может содержать только одну коллекцию любого заданного размера...

Нет причин, по которым Comparator должен возвращать те же результаты, что и equals(). На самом деле API Comparator был представлен потому, что equals() просто недостаточно: если вы хотите отсортировать коллекцию, вы должны знать, какие два элемента меньше или больше.

Немного странно, что SortedSet как часть стандартного API нарушает контракт, определенный в интерфейсе Set, и использует Comparator для определения равенства вместо метода equals, но так оно и есть.

Если ваша реальная проблема состоит в том, чтобы отсортировать набор коллекций в соответствии с размером содержащихся коллекций, вам лучше использовать список, который вы можете отсортировать с помощью Collections.sort(List, Comparator>);