Как предотвратить проверку null перед equals

Я нахожу такие вещи довольно раздражающими и уродливыми в equals методы:

if (field == null)
{
    if (other.field != null)
        return false;
}
else if ( ! field.equals(other.field))
    return false;

В C# я мог бы сделать это:

if( ! Object.Equals(field, other.field))
    return false;

есть ли что-то подобное в Java, или каков предпочтительный способ сделать это, если вещь?

9 ответов


использовать commons-lang:

org.apache.commons.lang.ObjectUtils.equals(Object object1, Object object2)

исходный код:

public static boolean equals(Object object1, Object object2) {
    if (object1 == object2) {
        return true;
    }
    if ((object1 == null) || (object2 == null)) {
        return false;
    }
    return object1.equals(object2);
}

От Apache

http://commons.apache.org/lang/

это примерно эквивалентно тому, что вы делаете в C#


Java 7 предлагает java.утиль.Объекты.равно.


гуавы равной что это :

public static boolean equal(@Nullable Object a, @Nullable Object b) {
    return a == b || (a != null && a.equals(b));
  }

или null шаблон объекта

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


Я бы написал это так:

return field != null && other.field != null && field.equals(other.field);

что не так элегантно, как строка кода C#, но намного короче дерева if, которое вы разместили.


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

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

даже если Oracle рекомендует методы equals быть null-safe, подумайте об этом: как только вы принимаете значения null, ваша модель становится хрупкой. Метод equals - не будет последним методом, в котором вы будете проверять значение null. Вы должны управлять проверками null в иерархии вызовов метода. Методы не могут быть повторно использованы из коробки больше. Вскоре каждый параметр будет проверяться на null.

Я видел обе стороны:

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

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


в рамках проекта Coin появилось предложение о добавлении серии null-безопасный операторов на Java. К сожалению, они не попали в Java 7, возможно, они появятся в Java 8. здесь - общее представление о том, как они будут работать


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

есть один способ

field == null ? false : true; / / поэтому в основном он будет возвращать true, когда он не равен null.

в groovy есть нулевой безопасный оператор для объектов. Возьмем пример для класса

A { 
 String name = "test1"
String surName = "test2"

public String returnName() {

 return name + surName
}

}

A a = null a?.name // Упомянутый оператор ? фактически проверит, является ли a null или нет. тогда он будет вызывать имя.

примечание: Я не применял двоеточие в коде, так как это не требуется в groovy.


строку.valueOf () решит некоторые из этих проблем, если toString реализован для ваших классов. Он выплюнет ответ toString() или "null", если указатель равен null.


Use == operator при проверке ссылок на объекты, если обе ссылки ссылаются на один и тот же объект, он вернет true. В противном случае, если вы ищете содержимое объекта, перейдите к нему.равно методу объектов.

so null означает, что у него нет никакого местоположения памяти, заданного в куче. Поэтому его можно просто проверить с помощью оператора'=='.