Как предотвратить проверку 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#
гуавы равной что это :
public static boolean equal(@Nullable Object a, @Nullable Object b) {
return a == b || (a != null && a.equals(b));
}
гуава также имеет несколько связанных цепи сравнения и другие плюсы.
Я бы написал это так:
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 означает, что у него нет никакого местоположения памяти, заданного в куче. Поэтому его можно просто проверить с помощью оператора'=='.