Primordial GetHashCode para objetos mutables?

Si tiene un objeto mutable, no tiene mucho sentido reemplazar el método GetHashCode, ya que realmente no puede usarlo. Se utiliza, por ejemplo, en las colecciones Dictionary y HashSet para colocar cada elemento en un cubo. Si cambia el objeto mientras se usa como clave en la colección, el código hash ya no coincide con el bucket en el que se encuentra el objeto, por lo que la colección no funciona correctamente y es posible que nunca vuelva a encontrar el objeto.

Si desea que la búsqueda no utilice el GetHashCode o Equals método de la clase, siempre puede proporcionar su propia implementación IEqualityComparer para usar en su lugar cuando cree el Dictionary.

El método Equals está destinado a la igualdad de valores, por lo que no está mal implementarlo de esa manera.

Wow, eso es en realidad varias preguntas en una : -). Así que uno tras otro:

Se ha citado que el valor de GetHashCode nunca debe cambiar durante la vida útil del objeto. ¿Cómo funciona si los campos en los que se basa son mutables?

Este consejo común está destinado para el caso en el que desea usar su objeto como clave en una tabla HASH/diccionario, etc. . Los HashTables generalmente requieren que el hash no cambie, porque lo usan para decidir cómo almacenar & recupera la llave. Si el hash cambia, la tabla hash probablemente ya no encontrará su objeto.

Para citar los documentos de la interfaz de Java Map:

Nota: se debe tener mucho cuidado si se utilizan objetos mutables como claves de mapa. El comportamiento de un mapa no se especifica si el valor de un objeto se cambia de una manera que afecta a las comparaciones iguales mientras que el objeto es una clave en el mapa.

En general, es una mala idea usar cualquier tipo de objeto mutable como clave en una tabla hash: Ni siquiera está claro qué debería suceder si una clave cambia después de haber sido agregada a la tabla hash. ¿La tabla hash debe devolver el objeto almacenado a través de la clave antigua, o a través de la nueva clave, o a través de ambas?

Así que el consejo real es: Solo use objetos inmutables como claves, y asegúrese de que su hashcode tampoco cambie (lo que generalmente es automático si el objeto es inmutable).

También qué pasa si quiero que las búsquedas de diccionario, etc. se basen en la igualdad de referencia ¿no mis Iguales anulados?

Bueno, encuentra una implementación de diccionario que funcione así. Pero los diccionarios de la biblioteca estándar usan el hashcode & Equals, y no hay manera de cambiar eso.

Estoy sobrescribiendo principalmente Equals para la facilidad de probar unitariamente mi código de serialización, que asumo que serializar y deserializar (a XML en mi caso) mata la igualdad de referencia, por lo que quiero asegurarme de que al menos sea correcta por igualdad de valor. Es esta mala práctica para reemplazar ¿Iguales en este caso?

El tema subyacente aquí es cómo identificar objetos de manera única. Usted menciona la serialización / deserialización que es importante porque la integridad referencial se pierde en ese proceso.

La respuesta corta, es que los objetos deben ser identificados de manera única por el conjunto más pequeño de campos inmutables que se pueden usar para hacerlo. Estos son los campos que debe usar al sobrescribir GetHashCode e Equals.

Para probar es perfectamente razonable definir cualquier aserción que necesidad, por lo general estos no se definen en el tipo en sí, sino más bien como métodos de utilidad en el conjunto de pruebas. Tal vez un TestSuite.assertEquals (MyClass, MyClass) ?

Tenga en cuenta que GetHashCode e Equals deberían trabajar juntos. GetHashCode debe devolver el mismo valor para dos objetos si son iguales. Equals debe devolver true si y solo si dos objetos tienen el mismo código hash. (Tenga en cuenta que es posible que dos objetos no sean iguales, pero pueden devolver el mismo código hash). Hay un montón de página web que aborda este tema de frente, solo google distancia.

Yo no sé acerca de C#, ser pariente de noob, pero en Java, si reemplazar equals() también es necesario reemplazar hashCode (), para mantener el contrato entre ellos (y viceversa)... Y Java también tiene el mismo catch 22; básicamente te obliga a usar campos inmutables... Pero esto es un problema solo para las clases que se utilizan como una clave hash, y Java tiene implementaciones alternativas para todas las colecciones basadas en hash... que tal vez no tan rápido, pero efectivamente le permiten utilizar un objeto mutable como llave... es solo (por lo general) fruncido el ceño como un "diseño pobre".

Y siento la necesidad de señalar que este problema fundamental es atemporal... Ha existido desde que Adam era un muchacho.

He trabajado en el código fortran que es más antiguo que yo (tengo 36 años) que se rompe cuando se cambia un nombre de usuario (como cuando una chica se casa o se divorcia ;-) ... Así es la ingeniería, La solución adoptada fue: El "método" GetHashCode recuerda el hashCode previamente calculado, recalcula el hashCode (es decir, un marcador IsDirty virtual) y si los campos de claves han cambiado devuelve null. Esto hace que la caché elimine al usuario "sucio" (llamando a otro GetPreviousHashCode) y luego la caché devuelve null, haciendo que el usuario vuelva a leer de la base de datos. Un truco interesante y que vale la pena; incluso si lo digo yo mismo; -)

Compensaré la mutabilidad (solo deseable en casos de esquina) por el acceso O(1) (deseable en todos los casos). Bienvenido a la ingeniería; la tierra de los informados compromiso.