Comentarios en: Cómo sobreescribir los métodos equals y hashCode de Java http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/ Wed, 20 Jul 2016 11:45:40 +0000 hourly 1 http://wordpress.org/?v=3.4 Por: Jose http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-49066 Jose Thu, 30 Jun 2016 06:20:19 +0000 http://anabuigues.com/?p=1051#comment-49066 Hola, buena mañana, una consulta, deseo sobreescribir un método que tiene tres variables, dos son de tipo String y una de tipo Double. Cuando haga el @Override y declare el tipo de la variable que voy a sobreescribir ¿cómo sería su declaración? Envío el ejemplo, la variable precio es de tipo Double, el toString sé que va enviar un dato de tipo String y otro de tipo booleano pero ¿qué ocurre con la variable precio? ¿cómo sería su correcta declaración? @Override public String toString(){ return "ProductoBean: " + this.nombre +this.tipo+this.precio; } Hola, buena mañana, una consulta, deseo sobreescribir un método que tiene tres variables, dos son de tipo String y una de tipo Double. Cuando haga el @Override y declare el tipo de la variable que voy a sobreescribir ¿cómo sería su declaración? Envío el ejemplo, la variable precio es de tipo Double, el toString sé que va enviar un dato de tipo String y otro de tipo booleano pero ¿qué ocurre con la variable precio? ¿cómo sería su correcta declaración?

@Override
public String toString(){
return “ProductoBean: ” + this.nombre +this.tipo+this.precio;
}

]]>
Por: his explanation http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-22357 his explanation Sun, 01 Mar 2015 02:58:47 +0000 http://anabuigues.com/?p=1051#comment-22357 <strong>his explanation...</strong> Cómo sobreescribir los métodos equals y hashCode de Java | El Blog de Ana Buigues... his explanation…

Cómo sobreescribir los métodos equals y hashCode de Java | El Blog de Ana Buigues…

]]>
Por: Berry http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-21507 Berry Fri, 20 Feb 2015 02:31:29 +0000 http://anabuigues.com/?p=1051#comment-21507 <strong>Berry...</strong> Cómo sobreescribir los métodos equals y hashCode de Java | El Blog de Ana Buigues... Berry…

Cómo sobreescribir los métodos equals y hashCode de Java | El Blog de Ana Buigues…

]]>
Por: Jose http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-13167 Jose Mon, 21 Jul 2014 16:37:29 +0000 http://anabuigues.com/?p=1051#comment-13167 Hola Ana, ¿cómo se sobrescribiría el método equals para un tipo enumerado? Gracias. Hola Ana, ¿cómo se sobrescribiría el método equals para un tipo enumerado?

Gracias.

]]>
Por: Efra http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-8950 Efra Wed, 18 Sep 2013 22:07:07 +0000 http://anabuigues.com/?p=1051#comment-8950 Ana, una duda, en todos lados veo que para el hashCode involucran siempre el número 31... ¿Es un tipo de convención? ¿Puedo usar mi propia manera de crear el hashCode? ¿Hay una implementación de referencia? Saludos. Ana, una duda, en todos lados veo que para el hashCode involucran siempre el número 31… ¿Es un tipo de convención? ¿Puedo usar mi propia manera de crear el hashCode? ¿Hay una implementación de referencia?

Saludos.

]]>
Por: Gaizka http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-7240 Gaizka Sun, 21 Apr 2013 21:26:30 +0000 http://anabuigues.com/?p=1051#comment-7240 Buenas Buena artículo. Quería hacerte un apunte. Dices: "Podemos excluir los campos que no comprobemos en el método equals, pero no es recomendable." Se deben excluir porque sino no garantizarías "Si dos objetos son iguales segun el método equals, entonces el hashCode de los dos objetos tiene que ser el mismo". Un saludo Buenas

Buena artículo. Quería hacerte un apunte.

Dices: “Podemos excluir los campos que no comprobemos en el método equals, pero no es recomendable.”

Se deben excluir porque sino no garantizarías “Si dos objetos son iguales segun el método equals, entonces el hashCode de los dos objetos tiene que ser el mismo”.

Un saludo

]]>
Por: Pablo http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-1578 Pablo Tue, 03 Apr 2012 19:33:38 +0000 http://anabuigues.com/?p=1051#comment-1578 La verdad excelente articulo me ha sido de mucha ayuda. Muchas gracias!! La verdad excelente articulo me ha sido de mucha ayuda.

Muchas gracias!!

]]>
Por: Gabriel http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-661 Gabriel Fri, 21 Oct 2011 20:10:50 +0000 http://anabuigues.com/?p=1051#comment-661 Buen articulo y me ha sido de gran ayuda , gracias. Buen articulo y me ha sido de gran ayuda , gracias.

]]>
Por: Ana Buigues http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-362 Ana Buigues Tue, 04 Jan 2011 16:48:16 +0000 http://anabuigues.com/?p=1051#comment-362 Hola Marcos, pues claro que puedes utilizarlo, todo sea por ayudar :D Un saludo! Hola Marcos, pues claro que puedes utilizarlo, todo sea por ayudar :D

Un saludo!

]]>
Por: Marcos Jara http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-361 Marcos Jara Tue, 04 Jan 2011 12:08:10 +0000 http://anabuigues.com/?p=1051#comment-361 Hola Ana, Buenisimo artículo, de hecho estoy preparando un entrenamiento para mis alumnos de la Universidad y voy a utilizar parte de la información que publicaste aqui... si me lo permites!!! :=) Un cordial Saludo. Hola Ana,

Buenisimo artículo, de hecho estoy preparando un entrenamiento para mis alumnos de la Universidad y voy a utilizar parte de la información que publicaste aqui… si me lo permites!!! :=)

Un cordial Saludo.

]]>
Por: Ana Buigues http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-303 Ana Buigues Mon, 15 Nov 2010 17:14:00 +0000 http://anabuigues.com/?p=1051#comment-303 Hola Sebastian, en Java tenemos diferentes tipos de excepciones dependiendo del tipo de error que representen. Todas ellas descienden de la clase Throwable. Aquí http://en.wikibooks.org/wiki/File:Java_exception_classes.jpg puedes ver el diagrama de clases que muestra cómo están relacionadas las excepciones en Java. <strong>Throwable</strong> tiene dos descendientes directos: * <strong>Error</strong>: Se refiere a errores graves en la máquina virtual de Java, como por ejemplo fallos al enlazar con alguna librería. Normalmente en los programas Java no se tratarán este tipo de errores. * <strong>Exception</strong>: Representa errores que no son críticos y por lo tanto pueden ser tratados y continuar la ejecución de la aplicación. La mayoría de los programas Java utilizan estas excepciones para el tratamiento de los errores que puedan ocurrir durante la ejecución del código. Dentro de Exception, tenemos las <strong>RuntimeException</strong> de la cual derivan todas aquellas excepciones referidas a los errores que comúnmente se pueden producir dentro de cualquier fragmento de código, como por ejemplo hacer una referencia a un puntero null, o acceder fuera de los límites de un array. Estas <strong>RuntimeException</strong> se diferencian del resto de excepciones en que no son de tipo checked. Una excepción de tipo checked debe ser capturada o bien especificar que puede ser lanzada de forma obligatoria, y si no lo hacemos obtendremos un error de compilación. Dado que las RuntimeException pueden producirse en cualquier fragmento de código, sería impensable tener que añadir manejadores de excepciones y declarar que éstas pueden ser lanzadas en todo nuestro código. Deberemos: * Utilizar<strong> excepciones unchecked</strong> (no predecibles) para indicar errores graves en la lógica del programa, que normalmente no deberían ocurrir. * Utilizar <strong>excepciones checked</strong> para mostrar errores que pueden ocurrir durante la ejecución de la aplicación, normalmente debidos a factores externos como por ejemplo la lectura de un fichero con formato incorrecto, un fallo en la conexión, o la entrada de datos por parte del usuario. Hola Sebastian, en Java tenemos diferentes tipos de excepciones dependiendo del tipo de error que representen. Todas ellas descienden de la clase Throwable. Aquí
http://en.wikibooks.org/wiki/File:Java_exception_classes.jpg puedes ver el diagrama de clases que muestra cómo están relacionadas las excepciones en Java.

Throwable tiene dos descendientes directos:
* Error: Se refiere a errores graves en la máquina virtual de Java, como por ejemplo fallos al enlazar con alguna librería. Normalmente en los programas Java no se tratarán este tipo de errores.
* Exception: Representa errores que no son críticos y por lo tanto pueden ser tratados y continuar la ejecución de la aplicación. La mayoría de los programas Java utilizan estas excepciones para el tratamiento de los errores que puedan ocurrir durante la ejecución del código.

Dentro de Exception, tenemos las RuntimeException de la cual derivan todas aquellas excepciones referidas a los errores que comúnmente se pueden producir dentro de cualquier fragmento de código, como por ejemplo hacer una referencia a un puntero null, o acceder fuera de los límites de un array.

Estas RuntimeException se diferencian del resto de excepciones en que no son de tipo checked. Una excepción de tipo checked debe ser capturada o bien especificar que puede ser lanzada de forma obligatoria, y si no lo hacemos obtendremos un error de compilación. Dado que las RuntimeException pueden producirse en cualquier fragmento de código, sería impensable tener que añadir manejadores de excepciones y declarar que éstas pueden ser lanzadas en todo nuestro código. Deberemos:
* Utilizar excepciones unchecked (no predecibles) para indicar errores graves en la lógica del programa, que normalmente no deberían ocurrir.
* Utilizar excepciones checked para mostrar errores que pueden ocurrir durante la ejecución de la aplicación, normalmente debidos a factores externos como por ejemplo la lectura de un fichero con formato incorrecto, un fallo en la conexión, o la entrada de datos por parte del usuario.

]]>
Por: Sebastian Cardona http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-298 Sebastian Cardona Thu, 11 Nov 2010 04:43:13 +0000 http://anabuigues.com/?p=1051#comment-298 Hola Ana, Gracias por tu respuesta, efectivamente el Netbeans los genera… lo anoto a mi lista de descuidos…XD… Quisiera comentar algo ya que hablas del <code>NullPointerException</code>, en Python vengo programando poco tiempo y en su Zen indican que: “Los errores nunca deberían dejarse pasar silenciosamente.”; ahora eso es Python, pero si lo llevamos a Java?... No sé, pero muchas veces una variable <code>null </code>me la ha jugado; puede que esto se deba a mi inexperiencia o a mi modo de programar…No sería más fácil darnos cuenta de lo que pasa con la variable en ese momento?... Puede este envuelto en otro de tantos paradigmas de programación y por eso me parezca conveniente…XD… Salu2 Hola Ana,
Gracias por tu respuesta, efectivamente el Netbeans los genera… lo anoto a mi lista de descuidos…XD…

Quisiera comentar algo ya que hablas del NullPointerException, en Python vengo programando poco tiempo y en su Zen indican que: “Los errores nunca deberían dejarse pasar silenciosamente.”; ahora eso es Python, pero si lo llevamos a Java?… No sé, pero muchas veces una variable null me la ha jugado; puede que esto se deba a mi inexperiencia o a mi modo de programar…No sería más fácil darnos cuenta de lo que pasa con la variable en ese momento?… Puede este envuelto en otro de tantos paradigmas de programación y por eso me parezca conveniente…XD…

Salu2

]]>
Por: Ana Buigues http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-293 Ana Buigues Tue, 09 Nov 2010 21:13:53 +0000 http://anabuigues.com/?p=1051#comment-293 Hola Sebastian, Efectivamente sí es necesaría la comprobación de null, es para evitar que al hacer: <code>direccion.equals(c.direccion)</code> el método equals devuelva la excepción NullPointerException. Puedes probar el siguiente código para verlo: <code>String direccion = null</code> <code>direccion.equals("loquesea")</code> Verás como produce un NullPointerException Si te fijas, el generador del hashCode del netbeans hace la misma comprobación: (suponiendo que el nombre es un String) <code>(this.nombre != null ? this.nombre.hashCode() : 0)</code> La verdad es que las últimas versiones del netbeans generan el equals y el hashcode siguiendo las propiedades, con lo que normalmente con ésta generación automática te será suficiente. Muchas gracias por tu comentario :) Hola Sebastian,
Efectivamente sí es necesaría la comprobación de null, es para evitar que al hacer:
direccion.equals(c.direccion)
el método equals devuelva la excepción NullPointerException.

Puedes probar el siguiente código para verlo:
String direccion = null
direccion.equals("loquesea")
Verás como produce un NullPointerException

Si te fijas, el generador del hashCode del netbeans hace la misma comprobación: (suponiendo que el nombre es un String)
(this.nombre != null ? this.nombre.hashCode() : 0)

La verdad es que las últimas versiones del netbeans generan el equals y el hashcode siguiendo las propiedades, con lo que normalmente con ésta generación automática te será suficiente.

Muchas gracias por tu comentario :)

]]>
Por: Sebastian Cardona http://anabuigues.com/2010/07/06/como-sobreescribir-los-metodos-equals-y-hashcode-de-java/#comment-288 Sebastian Cardona Tue, 09 Nov 2010 16:17:05 +0000 http://anabuigues.com/?p=1051#comment-288 Hola Ana, Felicitaciones!!!... me encanta la combinación de programación, ingles y diseño.... XD.. Excelente trabajo y espero que continúes con tu blog… Lo primero es agradecer, me fue realmente útil llevo un año con Java y nunca había visto la importancia de estos de sobrescribir esos métodos. Hallado que también es importante para el unitTesting; por que cuando se usa <code>assertEquals()</code>; en realidad se evaluada con el <code>equals() </code>del objeto, o eso parece según mis apreciaciones(Me devolvía False hasta que lo sobrescribí). Quisiera preguntar algo; Es necesario utilizar, cito: <code>if (direccion == null || !direccion.equals(c.direccion))</code> Sabiendo que en la docs del <code>String.equals() </code>indica que devuelve true, si no es null y es la misma cadana de caracteres. Creo que solo sería necesario esto: <code>if (direccion.equals(c.direccion))</code> Es para ir a favor de no repetir código… Mira y este código lo genero el Netbeans para el <code>hashCode(),</code> no sé si esta correcto: <code>int hash = 3; hash = 79 * hash + (this.nombre != null ? this.nombre. hashCode() : 0); hash = 79 * hash + (this.simbolo != null ? this.simbolo. hashCode() : 0); hash = 79 * hash + Float.floatToIntBits( this.valorConversion); return hash;</code> De nuevo muchas gracias por compartir… Que viva la cultura geek y la cultura Libre… Salu2 desde Colombia… Hola Ana,

Felicitaciones!!!… me encanta la combinación de programación, ingles y diseño…. XD.. Excelente trabajo y espero que continúes con tu blog…

Lo primero es agradecer, me fue realmente útil llevo un año con Java y nunca había visto la importancia de estos de sobrescribir esos métodos. Hallado que también es importante para el unitTesting; por que cuando se usa assertEquals(); en realidad se evaluada con el equals() del objeto, o eso parece según mis apreciaciones(Me devolvía False hasta que lo sobrescribí). Quisiera preguntar algo; Es necesario utilizar, cito:
if (direccion == null || !direccion.equals(c.direccion))
Sabiendo que en la docs del String.equals() indica que devuelve true, si no es null y es la misma cadana de caracteres. Creo que solo sería necesario esto:
if (direccion.equals(c.direccion))
Es para ir a favor de no repetir código… Mira y este código lo genero el Netbeans para el hashCode(), no sé si esta correcto:

int hash = 3;
hash =
79 * hash + (this.nombre != null ? this.nombre.
hashCode() : 0);
hash =
79 * hash + (this.simbolo != null ? this.simbolo.
hashCode() : 0);
hash =
79 * hash + Float.floatToIntBits(
this.valorConversion);
return hash;

De nuevo muchas gracias por compartir… Que viva la cultura geek y la cultura Libre…
Salu2 desde Colombia…

]]>