- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
class ........... {
BigDecimal t;
...
public boolean t_is_zero(){
BigDecimal zero = new BigDecimal(0);
if(this.t == zero)
return true;
else
return false;
}
...
}
Steve_Brown 12.11.2012 12:29 # −1
по сути будет то же самое.
3.14159265 12.11.2012 12:35 # +2
Во-вторых есть BigDecimal.ZERO.
Говно вот в чем:
>BigDecimal zero = new BigDecimal(0); //причем в методе, а не константа
Я промахнулся дважды - коммент плюсанул, а код минуснул. Надо было наоборот.
azv 12.11.2012 12:53 # 0
3.14159265 12.11.2012 13:00 # 0
bormand 12.11.2012 13:44 # 0
http://ideone.com/i0UAo4
Steve_Brown 12.11.2012 14:13 # 0
?
bormand 12.11.2012 14:48 # +1
roman-kashitsyn 12.11.2012 14:31 # +3
Вот такие вот ЖАБАПРОБЛЕМЫ
Steve_Brown 12.11.2012 14:44 # −1
roman-kashitsyn 12.11.2012 14:50 # +1
3.14159265 12.11.2012 16:17 # 0
В WeakReference да и во всех остальных "забыли" переопределить важные методы.
Сделать свой класс Ref с equals и hashCode.
Или WeakRef, StrongRef, SoftRef - по вкусу.
Билдить так Ref.weak(obj) ну или WeakRef.to(obj). В мапах польза неимоверная.
Пишется за две секунды, быдло очень боится.
roman-kashitsyn 12.11.2012 16:19 # 0
3.14159265 12.11.2012 17:52 # 0
Лол, хоть я не минусовал, но самое смешное что этот код тоже неправильный.
Comparable<T> означает вызов
compareTo(T o);
Если o2 is not T получим ошибку.
roman-kashitsyn 12.11.2012 17:59 # +2
3.14159265 12.11.2012 18:15 # 0
Но и это еще не всё. Там может быть какой-то Comparable<Time>, или там Comparable<Delayed> который, например сранивает по типу время создания.
Если мы напишем код выше, то объекты созданное в одно время будут равны ибо compareTo по времени идентичен.
А когда _внезапно_ окажется что объекты содержат поля о которых невозможно какое из них больше, а какое меньше, то вполне резонно, что в compareTo их учитывать никто не станет.
А equals наоборот их сранит правильно.
>очень рекомендуется сравнивать через compareTo()
Потому я сразу засомневался в полезности этой практики, не помню чтобы у Блоха такое было. Помню читал что надо при реализации класса из equals вызвать compareTo, по простой причине - не копипастить и не дублировать код.
Кстати разработчики что в BigInteger что в BigDecimal успешно на это забили.
PS: http://govnokod.ru/11813#comment155127
roman-kashitsyn 12.11.2012 18:30 # 0
"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, если это возможно.
3.14159265 13.11.2012 12:44 # 0
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 )).
Хотя по сути они равны.
3.14159265 13.11.2012 12:51 # +1
Можно найти либу, или обернуть как нравится.
Кстати из-за этого сраного BigDecimal пострадала и ни в чем не повинная скала.
http://govnokod.ru/12003
bormand 12.11.2012 14:49 # +1
roman-kashitsyn 12.11.2012 14:52 # +1
Там в основном жабо-аспекты, если вы не используете её на работе, оно вам врядли сильно пригодится. Хотя, есть некоторые интересные вещи, не зависящие от языка.
bormand 12.11.2012 15:14 # 0
Да тут мне задачку под ведроид подкинули... а там же жаба. Вот решил заодно ее подучить, чтобы не писать совсем уж быдлятский код, т.к. мой опыт работы с явой состоит из пары программок на J2ME да копания в клиенте Haven&Hearth.
Fai 12.11.2012 16:35 # +1
1. На каждый объект - одна обязанность.
2. Сущности должны быть открыты для расширения и закрыты от изменения.
3. Принцип подстановки Лисков.
4. Много специализированных интерфейсов лучше чем один общий.
5. Принцип инверсии зависимостей.
Пункты 3 и 5 лучше изучить отдельно, их в двух словах не описать.
bormand 12.11.2012 18:48 # +2
Fai 12.11.2012 21:48 # +2
Например:
bormand 12.11.2012 23:24 # +2
3.14159265 13.11.2012 12:33 # +2
Сам подход ПРАВИЛЬНО/НЕПРАВИЛЬНО написанный капсом уже неверен.
bormand 13.11.2012 12:43 # 0
Fai 13.11.2012 18:03 # 0
bormand 13.11.2012 18:04 # +2
Fai 14.11.2012 05:02 # −3
А если нужна скорость - в пизду объекты, надо писать на голой сишке.
roman-kashitsyn 14.11.2012 07:41 # +2
3.14159265 14.11.2012 13:32 # +1
А мне еще в известной пасте особо нравится этот кусок:
тебя ждет увлекательный мир хайлоада. Apache Hadoop, сверхбыстрые асинхронные key-value хранилища, MapReduce. Отсос хиккующих выблядков джава-хуесосов, которые сосут хуй по жизни
3.14159265 13.11.2012 18:18 # +1
http://govnokod.ru/7019
bormand 13.11.2012 18:22 # +1
3.14159265 12.11.2012 15:12 # +2
Такое же. Правда я прочел страниц 50 но потом забил.
>очень рекомендуется сравнивать через compareTo(), потому что equals() может быть реализован неправильно
>у Блоха это написано.
Кажись не. Спасибо, не знал. Еще одни грабли в копилочку equals.
Кстати подход предложенный @Steve_Brown MyTools. myEquals - я тоже считаю глубоко правильным.
Порочное ООП с его nullами и остальным говном не пройдёт.
Steve_Brown 12.11.2012 15:26 # 0
3.14159265 12.11.2012 15:46 # +1
Так лажа еще в том что есть Comparator и Comparable - очередной фейл жабы.
Ну как Enumeration и Iterator. Несмотря на иммутабельную полезность первого все используют итераторы только из-за Iterable и сахара в for()
Говно, говно повсюду.
govnomonad 12.11.2012 13:33 # +2
bormand 12.11.2012 12:59 # +1
P.S. Вот так правильно будет?