Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+71
class ........... {
BigDecimal t;
...
public boolean t_is_zero(){
BigDecimal zero = new BigDecimal(0);
if(this.t == zero)
return true;
else
return false;
}
...
}для операции сравнения была создана новая переменная как эквивалент )
Запостил: 
azv,
12 Ноября 2012
Follow us!
по сути будет то же самое.
Во-вторых есть BigDecimal.ZERO.
Говно вот в чем:
>BigDecimal zero = new BigDecimal(0); //причем в методе, а не константа
Я промахнулся дважды - коммент плюсанул, а код минуснул. Надо было наоборот.
http://ideone.com/i0UAo4
?
Вот такие вот ЖАБАПРОБЛЕМЫ
В WeakReference да и во всех остальных "забыли" переопределить важные методы.
Сделать свой класс Ref с equals и hashCode.
Или WeakRef, StrongRef, SoftRef - по вкусу.
Билдить так Ref.weak(obj) ну или WeakRef.to(obj). В мапах польза неимоверная.
Пишется за две секунды, быдло очень боится.
Лол, хоть я не минусовал, но самое смешное что этот код тоже неправильный.
Comparable<T> означает вызов
compareTo(T o);
Если o2 is not T получим ошибку.
Но и это еще не всё. Там может быть какой-то Comparable<Time>, или там Comparable<Delayed> который, например сранивает по типу время создания.
Если мы напишем код выше, то объекты созданное в одно время будут равны ибо compareTo по времени идентичен.
А когда _внезапно_ окажется что объекты содержат поля о которых невозможно какое из них больше, а какое меньше, то вполне резонно, что в compareTo их учитывать никто не станет.
А equals наоборот их сранит правильно.
>очень рекомендуется сравнивать через compareTo()
Потому я сразу засомневался в полезности этой практики, не помню чтобы у Блоха такое было. Помню читал что надо при реализации класса из equals вызвать compareTo, по простой причине - не копипастить и не дублировать код.
Кстати разработчики что в BigInteger что в BigDecimal успешно на это забили.
PS: http://govnokod.ru/11813#comment155127
"It is strongly recommended, but not strictly required, that (x.compareTo(y) == 0) == (x.equals(y))...
... general contracts for these interfaces (Collection, Set, Map) are defined in terms of the equals method, but sorted collections use the equality test imposed by compareTo in place of equals...
Because the Comparable interface is parameterized, the compareTo method is statically typed, so you don't need to type check or cast its
arguments..."
В общем, складывается тенденция использовать compareTo вместо equals, если это возможно.
The final paragraph of the compareTo contract, which is a strong suggestion
rather than a true provision, simply states that the equality test imposed by the
compareTo method should generally return the same results as the equals
method. If this provision is obeyed, the ordering imposed by the compareTo
method is said to be consistent with equals. If it’s violated, the ordering is said to
be inconsistent with equals. A class whose compareTo method imposes an order
that is inconsistent with equals will still work.
Собственно я нахожу эту практику сомнительной и не стал сравнивать объекты через compare ибо сиё условие необходимо для равенства. Но НЕ достаточно!
Заменять им equals, который сделан для сравнения - глупо. А если equals - неправильный это проблемы кривого класса, и мы не должны в клиентском коде затыкать их.
Со сравнениями чисел много нюансов.
Ведь никто ж не ожидает увидеть тут true:
Byte.valueOf(2).equals(Integer.valueOf(2 )).
Хотя по сути они равны.
Можно найти либу, или обернуть как нравится.
Кстати из-за этого сраного BigDecimal пострадала и ни в чем не повинная скала.
http://govnokod.ru/12003
Там в основном жабо-аспекты, если вы не используете её на работе, оно вам врядли сильно пригодится. Хотя, есть некоторые интересные вещи, не зависящие от языка.
Да тут мне задачку под ведроид подкинули... а там же жаба. Вот решил заодно ее подучить, чтобы не писать совсем уж быдлятский код, т.к. мой опыт работы с явой состоит из пары программок на J2ME да копания в клиенте Haven&Hearth.
1. На каждый объект - одна обязанность.
2. Сущности должны быть открыты для расширения и закрыты от изменения.
3. Принцип подстановки Лисков.
4. Много специализированных интерфейсов лучше чем один общий.
5. Принцип инверсии зависимостей.
Пункты 3 и 5 лучше изучить отдельно, их в двух словах не описать.
Например:
Сам подход ПРАВИЛЬНО/НЕПРАВИЛЬНО написанный капсом уже неверен.
А если нужна скорость - в пизду объекты, надо писать на голой сишке.
А мне еще в известной пасте особо нравится этот кусок:
тебя ждет увлекательный мир хайлоада. Apache Hadoop, сверхбыстрые асинхронные key-value хранилища, MapReduce. Отсос хиккующих выблядков джава-хуесосов, которые сосут хуй по жизни
http://govnokod.ru/7019
Такое же. Правда я прочел страниц 50 но потом забил.
>очень рекомендуется сравнивать через compareTo(), потому что equals() может быть реализован неправильно
>у Блоха это написано.
Кажись не. Спасибо, не знал. Еще одни грабли в копилочку equals.
Кстати подход предложенный @Steve_Brown MyTools. myEquals - я тоже считаю глубоко правильным.
Порочное ООП с его nullами и остальным говном не пройдёт.
Так лажа еще в том что есть Comparator и Comparable - очередной фейл жабы.
Ну как Enumeration и Iterator. Несмотря на иммутабельную полезность первого все используют итераторы только из-за Iterable и сахара в for()
Говно, говно повсюду.
P.S. Вот так правильно будет?