Tengo una clase de la siguiente manera:
public class Data{
int x;
ArrayList<Double> list;
}
Ahora, quiero pruebas de la unidad de escritura y comparar esta clase con otro simplemente para comprobar la igualdad. Sin embargo, quiero permitir cierto margen de error, de modo que incluso si los dobles son cercano con respecto a algunos épsilon son considerados iguales. Ahora, si sobrescribir los métodos equals () NetBeans método y Sonar pronta mí para reemplazar el método hashCode (), así que no tiene ningún sentido. La razón es que no es posible simplemente poner en práctica un método hashCode () que da salida al mismo valor de código hash para las listas CERRAR.
Mi pregunta es la siguiente:
¿Debo continuar con anulando el método equals () y hashCode acaba de anulación () por el bien de pasar cheque Sonar? (Una aplicación ficticia para hashCode ())
O
¿Debo poner en práctica este método para comprobar cercanía en mis pruebas de unidad y no en el código fuente real?
Esto parece un problema XY.
Usted está enredado en un asunto transitividad no trivial asociado con anulando equals()debido a la regla de negocio ( "si los dobles están cerca con respecto a alguna épsilon ..." ), como fuera de punta en un comentario a la OP.
De hecho, es imposible que pueda implementar de manera significativa un equals()método para esa regla, porque la transitividad ( " si x.equals (y) devuelve verdadero y y.equals (z) devuelve verdadero, entonces x.equals (z) debe devolver verdadero " ) no puede ser garantizada. Es posible que tenga tres Dataobjetos, D1, D2 y D3, donde d2 es igual (es decir, lo suficientemente cerca) a ambos D1 y D3, pero no era igual d1 (es decir, no lo suficientemente cerca) a d3.
No hay nada malo con las reglas impone Java cuando las pruebas de igualdad, y no hay nada malo en su condición específica para determinar la igualdad de los Datacasos tampoco. Es sólo que son incompatibles.
Sin embargo, aunque hay un montón de reglas que sin duda debe seguir si vas por la equals()ruta, no veo nada en su pregunta que indica que tiene para anular cualquier cosa. Así que no ir allí.
¿Por qué no acaba de crear un nuevo método public boolean sameAs(Object other)en la Dataclase? Se puede comprobar la igualdad basado en la regla (s), y las pruebas unitarias puede llamar a ese método. Entonces usted no tiene necesidad ni la obligación de poner en práctica equals()y hashCode()en lo absoluto.
(Actualizado el 09/12/19 a aclarar por qué equals()no se puede aplicar.)