Сообщение Re[4]: [Голосование] Нужен ли binary tree если есть hash таб от 20.06.2017 15:32
Изменено 20.06.2017 15:35 vsb
Re[4]: [Голосование] Нужен ли binary tree если есть hash таблица
Здравствуйте, scf, Вы писали:
scf>>>А вообще equals/hashCode на каждом объекте — великое изобретение Java, значительно увеличивающее её быстродействие.
vsb>>Можно раскрыть мысль? equals и hashCode из Object бесполезны чуть менее чем полностью. Мне никогда не нравилась эта куча мусора в Object.
scf>Это вопрос дизайна языка. equals/hashСode в Object подталкивают программистов к их переопределению в собственных объектах, тем более, что equals почти всегда нужен, а правила соответствия equals/hashСode вдалбливаются начинающим программистам с самого начала изучения языка.
Не знаю, я вроде не начинающий программист, но меня это никуда не подталкивало никогда. Если реально нужен equals — переопределяю. Если объект в виде ключа в хеш-таблице используется — переопределяю hashCode. Просто так — зачем, это же мёртвый код, а к нему по-хорошему и тесты писать надо и в будущем поддерживать.
scf>>>А вообще equals/hashCode на каждом объекте — великое изобретение Java, значительно увеличивающее её быстродействие.
vsb>>Можно раскрыть мысль? equals и hashCode из Object бесполезны чуть менее чем полностью. Мне никогда не нравилась эта куча мусора в Object.
scf>Это вопрос дизайна языка. equals/hashСode в Object подталкивают программистов к их переопределению в собственных объектах, тем более, что equals почти всегда нужен, а правила соответствия equals/hashСode вдалбливаются начинающим программистам с самого начала изучения языка.
Не знаю, я вроде не начинающий программист, но меня это никуда не подталкивало никогда. Если реально нужен equals — переопределяю. Если объект в виде ключа в хеш-таблице используется — переопределяю hashCode. Просто так — зачем, это же мёртвый код, а к нему по-хорошему и тесты писать надо и в будущем поддерживать.
Re[4]: [Голосование] Нужен ли binary tree если есть hash таб
Здравствуйте, scf, Вы писали:
scf>>>А вообще equals/hashCode на каждом объекте — великое изобретение Java, значительно увеличивающее её быстродействие.
vsb>>Можно раскрыть мысль? equals и hashCode из Object бесполезны чуть менее чем полностью. Мне никогда не нравилась эта куча мусора в Object.
scf>Это вопрос дизайна языка. equals/hashСode в Object подталкивают программистов к их переопределению в собственных объектах, тем более, что equals почти всегда нужен, а правила соответствия equals/hashСode вдалбливаются начинающим программистам с самого начала изучения языка.
Не знаю, я вроде не начинающий программист, но меня это никуда не подталкивало никогда. Если реально нужен equals — переопределяю. Если объект в виде ключа в хеш-таблице используется — переопределяю hashCode. Просто так — зачем, это же мёртвый код, а к нему по-хорошему и тесты писать надо и в будущем поддерживать. А вот забыть и использовать вполне можно. Было бы по уму сделано, такой код не скомпилировался бы. По-хорошему должны быть интерфейсы Equatable, Hashable, так же как Comparable и если нужны соотв. методы, реализуешь интерфейс. Либо, что ещё правильней, определять отдельные объекты вроде Equator, Hasher по аналогии с Comparator и передавать их в соотв. структуры данных.
scf>>>А вообще equals/hashCode на каждом объекте — великое изобретение Java, значительно увеличивающее её быстродействие.
vsb>>Можно раскрыть мысль? equals и hashCode из Object бесполезны чуть менее чем полностью. Мне никогда не нравилась эта куча мусора в Object.
scf>Это вопрос дизайна языка. equals/hashСode в Object подталкивают программистов к их переопределению в собственных объектах, тем более, что equals почти всегда нужен, а правила соответствия equals/hashСode вдалбливаются начинающим программистам с самого начала изучения языка.
Не знаю, я вроде не начинающий программист, но меня это никуда не подталкивало никогда. Если реально нужен equals — переопределяю. Если объект в виде ключа в хеш-таблице используется — переопределяю hashCode. Просто так — зачем, это же мёртвый код, а к нему по-хорошему и тесты писать надо и в будущем поддерживать. А вот забыть и использовать вполне можно. Было бы по уму сделано, такой код не скомпилировался бы. По-хорошему должны быть интерфейсы Equatable, Hashable, так же как Comparable и если нужны соотв. методы, реализуешь интерфейс. Либо, что ещё правильней, определять отдельные объекты вроде Equator, Hasher по аналогии с Comparator и передавать их в соотв. структуры данных.