Igualdad de objetos es relativa al contexto

Igualdad

boolean equals públicos (Object otro)

es fundamentalmente errónea porque no hay una definición de igualdad que funcione en todos los contextos.

Tomemos, por ejemplo, la cuestión de la entrada del usuario y el mecanismo de escape . TaintedString es un simple envoltorio para cuerdas, que comparte las mismas firmas de método, pero no antepasado común. Toda la entrada del usuario debe ser convertida en TaintedStrings para demostrar que no es de confianza. No Formatos de salida deben aceptar una TaintedString – debe ser codificada de acuerdo con el tipo de salida antes de escribirlos. Pero ensuciar a comprobar un objeto persistente para el ahorro, es necesario comparar la cadena en bruto de la base de datos a un TaintedString del usuario para ver si ha cambiado. Así, en un contexto, una clase debe ser igual en realidad una clase que es totalmente ajeno desde el punto de vista de la herencia. Pero en la mayoría de los contextos, desea TaintedString y cuerdas para ser totalmente incompatible de modo que no se puede escribir accidentalmente un TaintedString a la salida sin antes de codificarlo.

hashCode () , Equals (Object otro) , y compareTo (Object otro) son muy bien para la definición de la igualdad y el orden en una sola (por defecto) contexto. ¿Qué pasa con múltiples contextos? La interfaz Comparator tiene una comparar (o1 objetos, o2 Object), que compara dos objetos en un contexto determinado . Ahora puedes ordenar las personas por el apellido en orden alfabético en un libro de teléfono utilizando un comparador, y en otro contexto por el orden en que llegaron a comprar boletos utilizando otro Comparator. Pero Comparador está genericized para trabajar con un solo tipo de objeto

En cuanto a algunos de los códigos de hibernación de esta mañana, me encontré con el siguiente método:.

  boolean equals públicos ( Object o, o2 Object)  

Aquí, por fin, es una manera de comparar un TaintedString a una cadena a pesar de que no comparten un ancestro común (además de Object) o implementan una interfaz común. Debido al contrato entre hashCode (), es igual a () y comparador, pruebas de la igualdad y de hash debe estar vinculada a la interfaz Comparator. Comparador ya define la igualdad - devuelve 0 cuando las cosas son iguales, algo más de lo contrario. Tener un independiente es igual () en absoluto es esencialmente una optimización del rendimiento. El imlementation defecto de Comparator.hashcode (Object o) puede ser o.hashcode retorno (); . Esto podría ser anulado cuando eso podría ser incompatible con los otros métodos.

Inspiration

Sets Mapeo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *