Назначение полей в методе equals()

Question

Предположим, что у вас есть написанный класс и использовали ленивую инициализацию для назначения одного из своих полей. Предположим, что вычисление для этого поля связано только с другими полями и гарантируется, что каждый раз он будет получать одинаковый результат. Когда два равных экземпляра класса встречаются друг с другом, им разумно делиться значением лениво инициализированного поля (если оно известно). Вы можете сделать это в методе equals(). Вот класс, показывающий, что я имею в виду.

final class MyClass { 

    private final int number; 
    private String string; 

    MyClass(int number) { 
     this.number = number; 
    } 

    String getString() { 
     if (string == null) { 
      string = OtherClass.expensiveCalculation(number); 
     } 
     return string; 
    } 

    @Override 
    public boolean equals(Object object) { 
     if (object == this) { return true; } 
     if (!(object instanceof MyClass)) { return false; } 
     MyClass that = (MyClass) object; 
     if (that.number != number) { return false; } 
     String thatString = that.string; 
     if (string == null && thatString != null) { 
      string = thatString; 
     } else if (thatString == null && string != null) { 
      that.string = string; 
     } 
     return true; 
    } 

    @Override 
    public int hashCode() { return number; } 
} 

Для меня это обмен информацией, кажется логичным, чтобы сделать, если вы собираетесь пойти на усилия лениво инициализирует поля, но я никогда не видел пример, кто использует метод equals() в этом путь.

Это обычная или стандартная техника? Если да, то как это называется? Если это не обычная техника, могу ли я спросить (рискуя поставить вопрос о том, чтобы удержать вопрос в основном на основе мнения), что люди думают об этом? Это хорошая идея использовать метод equals() для выполнения каких-либо иных действий, кроме проверки равенства?

Answer 1

подхода вы охарактеризовали иногда хороший, особенно в ситуациях, когда, вероятно, многие крупные неизменные объекты, несмотря на независимость, будут в конечном итоге идентичны. Поскольку сравнивать сравнительные ссылки по сравне нию гораздо быстрее, чем сравнивать большие объекты, которые оказываются равными, может быть полезно иметь код, который сравнивает два больших объекта и находит их идентичными, заменяя одну из ссылок ссылкой на другую , Чтобы это было осуществимо, нужно попытаться установить какой-то порядок между рассматриваемыми объектами, чтобы гарантировать, что повторные сравнения в конечном итоге принесут ту же каноническую ценность. Это может быть достигнуто за счет того, что объекты включают порядковый номер long и последовательно заменяют ссылки на более новые значения ссылками на значения более старого, но равного или сравнивая значение равных ссылок и отбрасывая, в зависимости от того, какая из них имеет, если таковые имеются, более низкую value (если две ссылки, которые идентифицируют отдельные, но идентичные экземпляры, сообщают о том же identityHashCode, оба должны быть сохранены).

Отвратительная, но неудачная морщина в том, что у Java очень плохая многопоточная поддержка для эффективно-неизменяемых объектов. Для эффективно-неизменяемого объекта, который должен быть потокобезопасным, любой доступ к массиву или не-final должен пройти через поле final. Самый дешевый способ выполнения этого, вероятно, состоит в том, чтобы объект содержал поле final, в которое он хранит ссылку на себя, и имеет все методы, которые получают доступ к полям final, таким образом, что это поле final, но это немного уродливо. Тем не менее, изменение ссылок на отдельные, но идентичные ссылки со ссылками на один и тот же объект может дать некоторые существенные преимущества в производительности, несмотря на глупый избыточный final доступ к полю (поскольку цель конечного поля будет гарантирована быть в кэше, разыменование будет намного дешевле обычного разыменования).

Кстати, во многих случаях можно было бы включить механизм «эквивалентности-отношения», чтобы после того, как некоторые объекты были сопоставлены и оказались равными, обнаружение того, что любой из них равен другому объекту, вызовет их все чтобы быть быстро узнаваемыми как таковые. Однако я не понял, как избежать возможности преднамеренно-противной, но законной схемы использования, вызывающей утечку памяти.

Answer 2

Это выглядит опасно для меня: использование побочного эффекта открытого метода объекта для установки состояния объекта. Это сломается, если вы подклассифицируете этот класс, а затем переопределите метод equals подкласса, что обычно нужно делать. Только не делай этого.

Answer 3

«Предположим, что вычисление для этого поля связано только с другими полями и гарантирует, что каждый раз будет получать одинаковый результат».

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

Редактировать Я предполагаю, что я обошел оригинальный вопрос, поэтому я тоже отвечу на него. В сценарии, который вы создали, нет ничего неправильного в том, что вы предлагаете.

Аргумент, который я хотел бы сделать, - это просто с прагматической точки зрения: что происходит, когда кто-то меняет определение getString() (или, скорее всего, меняет определение долгосрочного расчета, которое приводит к этому значению), и оно начинает полагаться на что-то, что не является частью соображений равенства объекта?

Причина, по которой общепринятая мудрость говорит о том, что equals() должен быть свободным от побочных эффектов, заключается в том, что большинство разработчиков ожидают, что он будет свободным от побочных эффектов.

Answer 4

Я бы не сделать это, по трем причинам:

1. Общие принципы программно-инженерные, такие как сплоченность, слабая связь, и «не повторять себя», препятствовать против него: вашего метода equals(...) будет делать что-то не очень «равно» -y, которое перекрывается с логикой вашего метода getString(). Кто-то, обновляющий логику getString(), вполне может не заметить, нужно ли также обновлять логику equals(...). (Вы можете подумать, что логика equals(...) будет по-прежнему правильной, независимо от того, , какgetString() изменен — В конце концов, у вас только есть equals(...) скопируйте ссылку с одного объекта на эквивалентный, так что предположительно это должно всегда оставаться то же самое? —, но проблема в том, что сложные системы развиваются так, что вы не всегда можете предсказать заранее.Когда изменяется требование, вы не хотите делать случайные изменения в частях кода, которые явно не связаны с этим требованием.)

2. Безопасность резьбы. Ваше поле string в настоящее время не volatile, а ваш метод getString() в настоящее время не synchronized, поэтому здесь нет никакой попытки обеспечить безопасность потоков; но если бы вы сделали остальную часть класса потокобезопасной, было бы совершенно невозможно изменить equals(...), чтобы быть потокобезопасным, не рискуя взаимоблокировками. (Это немного перекрывается с точкой № 1, но я перечисляю его отдельно, потому что # 1 касается только сложности с пониманием , что у вас есть изменение equals(...), тогда как эта проблема немного сложна, чтобы адресовать даже , учитывая, что знания.)

3. Неповторимость. Существует не так много причин ожидать, что это произойдет очень часто, что два экземпляра получают equals(...) -компрометированные, когда один уже был инициализирован ленивым, а другой - нет; поэтому дополнительная сложность кода и недостатки, упомянутые выше, вряд ли будут стоить того. (Помните: код не является бесплатным. Для того, чтобы пройти стоимость анализа, преимущества части кода должны превышать затраты на тестирование, понимание, поддержание и поддержку в будущем.) Если стоит поделиться этими ленивыми -инициализированные значения между эквивалентными экземплярами, то это должно быть сделано более ясным и более организованным способом, который не зависит от случайности. (Например, вы можете сделать конструктор приватным классовым, и есть static фабрика-метод, который проверяет staticWeakHashMap для существующего экземпляра до создания и возвращения нового.)