Есть класс

У кого-нибудь есть идеи почему это некорректная имплементация equals? Подчеркну, что речь идет именно о реализации метода equals(), а не о том, что тут не переписан hashCode()

Добавлено через 44 секунды
Ты, наверно, имел ввиду переопределение.

Верно сообразил. Молодец Platon +1 за внимательность.

Че-то седня ты целый день вопросами сыпешь ;) я так с тобой авторитетным челом стану

ClassCastException не боитесь поймать?

И правда что!! Приношу свои извинения, абсолютно правильная поправка.

fixxer, Да абсолютно верно это тоже надо учитывать.

ClassCastException  уже боимся, надо бы ещё и NPE забояться в 






Это сообщение отредактировал(а) mindflyer - 18.10.2007, 10:16

Ээй, хватит! Так вы на этом участке скоро и OutOfMemoryException перехватывать будете!

А Null успешно ловится на проверке instanceof, так что это, право, лишнее.

Shaggie Справделивости ради OutOfMemoryError, а не exception... ну и я думаю никому не надо объяснять что error'ы никто не ловит, на то они и Error'ы

Не-а. Exception. И его можно перехватить и обработать. Столкнулся с ним при работе с картинками - распакованные в памяти jpeg занимают очень много места, стандартных 64 мегабайт кучи не хватает и вылетает Exception.

Вот что говорит гугл

Shaggie, Еще разок в JavaAPI такого Exception'а нет, Он может появиться только если его кто то написал для своих никому неведомых целей, а гугл иногда говорит глупости

Так... а поиск по java.sun.com тоже глупости говорит?

Гы  Вспомнили таки о NPE )

В данном случае проверка необходима. instanceof делается для сравниваемого объекта, я же написал о равенству null поля объекта.

И? В данном случае методы this.name не вызываются и NPE не случится. Все корректно отработает.

fixxer, Shaggie, для тех, кто не боится NPE:

Согласен.

Shaggie, Ты скажи, что пытаешься доказать? Что такой класс есть JavaAPI? Такого класса там нет! То что на сановых форумах поиск выводит OutOfMemoryException то это только лишь от того что многие его участники забывают, что OutOfMemory бывает только Error и пишут по привычке Exception

Разница в инстансоф и сравнении по getClass ну и.... нуллы - э то нуллы. Они есть и будут есть. Зачем такой абстрактный иквалз нужен?
Сферический конь в вакууме или принцесса, которая не какает.

Точно!   
Во тема, блин  
Вопрос не по теме, но зачем сделано через отрицания в "return !(str != null ? !str.equals(tmp.str) : tmp.str != null);"? Исходя из каких-то соображений?

(offtopic) нигилизм наверное )

Добавлено @ 09:29
Если уже сильно нада сравнить, то я бы сделал так:



Это сообщение отредактировал(а) jsse - 19.10.2007, 09:30

Royan, ок, принято. Свою ошибку признаю. Дома потестил - в самом деле Error вылетает, так что невнимательность на мне.

Механизм exception работает очень медленно по сравнению с обычными проверками (if, instanceof,...), не знаю какова разница в современной java, но про 1.4 видел в литературе высказывание о простых случаях (как рассматриваемый в этом топике) - "в десятки раз медленнее".

Это сообщение отредактировал(а) mindflyer - 19.10.2007, 11:14

mindflyer, я описал ситуацию если нужно очень получить ответ, но не скорость выполнения ), хотя было бы интересно узнать факты и примеры где Exсeption отрабатует "в десятки раз медленнее"!

Оптимизейшн.  IDE предложила соптимизнуть - я согласился  Было длиннее.


Вообще, эксепшн - это когда идёт что-то не так по нашей или чужой вине. "Соломка подстеленная на всякий случай".
А управление нормальным ходом программы с помощьюэксепшнов - плохой стиль.
Всё равно как вместо
if(obj == null){
  <blah-blah>
}

писать
try{
if(obj.getName == "ewe")
}catch(NullPointerException e){
  <blah-blah>
}
Суть ни капли не меняется, но читать удобнее и правильнее

chief39, еще хуже стиль когда в каждом сравнении типа if идет return

То есть?
Типа:
return x!=5;
да?

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

То бишь, есть претензии по варианту с несколькими ретурнами? 
Можно пояснить свою личную точку зрения? 

chief39, обычно код одной ф-ции не занимает 5 строк ) Например сложно будет читать код в котором 10 return на 20 строк кода.

Это сообщение отредактировал(а) jsse - 19.10.2007, 12:12

Ща пофантазирую... 10 return - это 10 различных (!) ситуаций, из-за которых выполнение функции может завершиться досрочно. Причём не все они выбрасывают исключение. Значит, надо для отслеживания некоторых ситуаций писать собственные исключения.

Если мы вместо 10 возвратов используем один большой трай-кетч блок, то сразу потеряем возможность отслежить причину выброшенного исключения, чтобы соответствующим образом отреагировать.

А если используем 10 разных трай-кетч блоков, причём вложим их так, чтобы при вылетании исключения выполнение метода завершалось с нужным нам результатом, то можно будет в паспорте в графе "национальность" вписывать "индус".

Предпочитаю честные возвраты.

Shaggie, хаха! посмеялся +1.  Я еще раз повторюсь - один из вариантов который я предложил, чтоб избежать ошибок - завернул в "Exception", но конечно, скорее всего, лучше было бы получить с помощью сравниния всевозможных ситуаций, и возможно, это правильней и производительней ) Всё равно как ни крути любая программа содежит минимум 3 ошибки. А на счет return в середине блока, даже в книге Шилдта и Нортона, которых стояли у истоков языка, не рекомендовали использовать возврат в середине функции. Да и как по мне, сложнее читать чужой код когда ищешь где функция должна вернуть тебе ответ, согласитесь гораздо проще увидеть что на входе(вызов функции) и что на выходе(возврат - return).

Шилдт и Нортон попсовики-писатели, им все равно про что боянить Java, C++, .Net

В книге Джоша Блоха "Effective Java" в главе посвящённой equals он как раз не гнушается использовать возвраты точь в точь как chief39. А ведь товарищ - архитектор Java, его фамилию можно наблюдать в исходных кодах.

Каждому своё.

Что значит попсовики-писатели??

Добавлено через 4 минуты и 40 секунд
Shaggie, конечно - это то же что и обсуждать стиль написания программы. каждому своё, но есть стандарты.

Добавлено через 11 минут и 42 секунды
Shaggie, Книгу конечно полистаю "Effective Java: Programming Language Guide
 By Joshua Bloch"

Shaggie, где можно взять русский перевод?

Как пишет Мартин Фаулер (и я с ним полностью согласен на основе своего опыта) идея одной точки выхода (избегание возвратов в разных местах функции) - очень эффективна в рамках концепции структурного программирования. Однако, java это уже ООП, в котором размер методов как правило невелик, и обычно гораздо проще понимать код, когда выход из функции происходит именно в тот момент (в той точке), когда становится ясно, что дальнейшая его работа уже не нужна. Потому лично я сторонник стиля, о котором пишет chief39

Обычно методы(не функции! это важно в данном контексте) по сути и не требуют десяти ретурнов. Но требют по логике работы парочки throw. Т.к. могут быть неопределённости в процессе выполнения.
А супербольшие методы - это уже зло.

А вот методы, подобные иквалз и хэшкод - довольно специфичны по задаче своей.
Большинство методов работают с какими-то осмысленными крупнозернистыми операциями.
А такие сервис-методы имеют задачей "проверить все поля и сказать ДА или НЕТ".
Упомянутые недавно КА этим и занимаются. И лучше оптимизировать, дабы не танцевать вокруг всего объекта, если по первому пропери уже ясно что ОБЪЕКТ НЕ КАНАЕТ.
Джавасоздатели зачем-то сделали короткое замыкание в логических выражениях  Неужто в этом тоже нет смысла?   

По логике А:
"тэк, взяли объект, ага.. он налл - всё, до свиданья! Не налл? Аха.. проверяем дальше, что там в следующем проперти? ...."
По логике В:
"взяли. попробовали. налл. эксепшн. так. теперь пошли ловить эксепшн. ага, поймали, выходим."
Или ещё лучше:
"ага, налл.. запишем в переменную метода. так, пошли дальше, дальше, дальше, дальше... ага. конец. тааак... что там с переменной? ага.. не подошло ещё в саомм начале... тэээк-с.. начинаем выходить из метода".
Красиво, кто ж спорит   

Имхо, дискуссия на тему throw/if-return не имеет смысла. Оба имеют свои пределы применения, обоими можно злоупотреблять. Не будете же вы все if заменять на throw. И наоборот. Так чего спорить-то? 
Предпочитаете кидать эксепшены - кидайте. Если переборщите, сами услышите "запах" кода.   
То же самое и в обратном направлении.

Вот правильно реализованный метод equals()

Во-первых, метод equals() не должен породить NullPointerException, если аргумент == null. Читаем javadoc:

Во-вторых, если вы используете instanceof вместо однозначной идентификации класса, вам стоит сделать метод equals() финальным. Потому что в ином случае наследник вашего класса может нарушить одно важное правило:

В инете - не знаю, а в книжном видел за 280 р., попробуй поискать. Чуть не купил... денег с собой не было. Красноярск.

Причем сами создатели JDK нарушают это правило 

Добавлено через 4 минуты и 14 секунд
Хотя по мне, реализация через getClass() не самая лучшая.