¿Cuáles son esos números mágicos que se ven a menudo en las implementaciones de GetHashCode?

Son números primos. Los números primos se utilizan para crear códigos hash porque los números primos maximizan el uso del espacio de código hash.

Específicamente, comience con el número primo pequeño 3, y considere solo el orden bajo nybbles de los resultados:

• 3 * 1 = 3 = 3(mod 8) = 0011
• 3 * 2 = 6 = 6(mod 8) = 1010
• 3 * 3 = 9 = 1(mod 8) = 0001
• 3 * 4 = 12 = 4(mod 8) = 1000
• 3 * 5 = 15 = 7(mod 8) = 1111
• 3 * 6 = 18 = 2(mod 8) = 0010
• 3 * 7 = 21 = 5(mod 8) = 1001
• 3 * 8 = 24 = 0(mod 8) = 0000
• 3 * 9 = 27 = 3(mod 8) = 0011

Y empezamos de nuevo. Pero te darás cuenta de que múltiplos sucesivos de nuestro primo genera cada permutación posible de bits en nuestro nybble antes de empezar a repetir. Podemos obtener el mismo efecto con cualquier número primo y cualquier número de bits, lo que hace que los números primos sean óptimos para generar códigos hash casi aleatorios. La razón por la que generalmente vemos primos más grandes en lugar de primos pequeños como 3 en el ejemplo anterior es que, para un mayor número de bits en nuestro código hash, los resultados obtenidos al usar un primo pequeño ni siquiera son pseudo-aleatorios, simplemente son una secuencia creciente hasta que se encuentra un desbordamiento. Para una aleatoriedad óptima, un número primo que resulta en desbordamiento para coeficientes bastante pequeños debe ser utilizado, a menos que pueda garantizar que sus coeficientes no serán pequeños.

Enlaces Relacionados:

• ¿Por qué se utiliza' 397 ' para ReSharper GetHashCode override?

Echa un vistazo a Directrices y reglas para GetHashCode por Eric Lippert

Debe sobrescribirlo siempre que tenga una medida significativa de igualdad para objetos de ese tipo (es decir, sobrescribir Iguales). Si supieras que el objeto no iba a ser hash por cualquier razón, podrías dejarlo, pero es poco probable que lo sepas de antemano.

El hash debe basarse solo en las propiedades del objeto que se utilizan para definir la igualdad, ya que dos objetos que se consideran iguales deben tener el mismo código hash. En general, normalmente harías algo como:

public override int GetHashCode()
{
    int mc = //magic constant, usually some prime
    return mc * prop1.GetHashCode() * prop2.GetHashCode * ... * propN.GetHashCode();
}

Normalmente asumo que multiplicar los valores juntos producirá una distribución bastante uniforme, asumiendo que la función hashcode de cada propiedad hace lo mismo, aunque esto puede estar mal. Usando este método, si las propiedades que definen la igualdad de los objetos cambian, entonces el código hash también es probable que cambie, lo cual es aceptable dada la definición #2 en su pregunta. También se ocupa de todos los tipos de manera uniforme.

Puede devolver el mismo valor para todas las instancias, aunque esto hará que cualquier algoritmo que use hash (como dictionarys) sea muy lento, esencialmente todas las instancias serán hash en el mismo bucket y la búsqueda se convertirá en O(n) en lugar del esperado O(1). Esto, por supuesto, niega cualquier beneficio de usar tales estructuras para la búsqueda.

¿Por qué tengo que anular object.GetHashCode()?

Sobrescribir este método es importante porque la siguiente propiedad siempre debe permanecer verdadera:

Si dos objetos se comparan como iguales, el método GetHashCode para cada objeto debe devolver el mismo valor.

La razón, según lo declarado por JaredPar en un blog post sobre la implementación de la igualdad, es que

Muchas clases usan el código hash para clasificar un objeto. En particular, las tablas hash y los diccionarios tienden a colocar objetos en cubos basados en su código hash. Al comprobar si un objeto ya está en la tabla hash, primero lo buscará en un cubo. Si dos objetos son iguales pero tienen diferentes códigos hash, se pueden poner en diferentes cubos y el diccionario fallaría al buscar el objeto.

Enlaces relacionados:

• ¿TENGO que anular GetHashCode e Igual en Clases nuevas?
• Necesito anular GetHashCode () en ¿tipos de referencia?
• Override Equals and GetHashCode Question
• ¿Por qué es importante sobrescribir GetHashCode cuando el método Equals se sobrescribe en C#?
• Implementación adecuada de la Igualdad en VB

A) Debe sobrescribir ambos Equals y GetHashCode si desea emplear igualdad de valor en lugar de la igualdad de referencia predeterminada. Con el último, dos referencias de objetos se comparan como iguales si ambas se refieren a la misma instancia de objeto. Con los primeros se comparan como iguales si su valor es el mismo incluso si se refieren a objetos diferentes. Por ejemplo, es probable que desee emplear la igualdad de valor para los objetos Fecha, Dinero y Punto.

B) Con el fin de implementar la igualdad de valor que debe anular Equals y GetHashCode. Ambos deben depender de los campos del objeto que encapsulan el valor. Por ejemplo, Fecha.Año, Fecha.Mes y Fecha.Día; o Dinero.Moneda y Dinero.Cantidad; o Punto.X, Punto.Y y Punto.Z. También debe considerar sobreescribir operator==, operator != , operator .

C) El hashcode no tiene que permanecer constante durante toda la vida útil del objeto. Sin embargo, debe permanecer inmutable mientras participa como clave en un hash. De MSDN doco for Dictionary: "Mientras un objeto se utilice como clave en el Diccionario)>), no debe cambiar de ninguna manera que afecte a su valor hash."Si debe cambiar el valor de una clave, elimine la entrada del diccionario, cambie el valor de la clave y reemplace la entrada.

D) IMO, simplificarás tu vida si tus objetos de valor son inmutables.

¿Cuándo anulo object.GetHashCode()?

Como MSDN dice:

Los tipos que anulan Iguales también deben anular GetHashCode ; de lo contrario, Hashtable podría no funcionar correctamente.

Enlaces Relacionados:

• ¿Cuándo sobrescribir GetHashCode ()?

¿En qué campos basar el código hash? Si solo debe estar en campos inmutables, ¿qué pasa si solo hay campos mutables?

No necesita estar basado solo en campos inmutables. Lo basaría en los campos que determinan el resultado del método igual.

Cómo asegurarse de que el código hash permanezca igual durante toda la vida útil del objeto. (MSDN Propiedad #2) Especialmente cuando la igualdad se basa en campos mutables. (MSDN Propiedad #1)

Usted parece malinterpretar la Propiedad #2. El hashcode no necesita permanecer igual durante toda la vida útil de los objetos. Solo tiene que permanecer igual, siempre y cuando los valores que determinan el resultado del método igual no se cambian. Así que lógicamente, basas el hashcode solo en esos valores. Entonces allí no debería ser un problema.

public override int GetHashCode()
{
    return IntProp1 ^ IntProp2 ^ StrProp3.GetHashCode() ^ StrProp4.GetHashCode ^ CustomClassProp.GetHashCode;
}

Haga lo mismo en el método GetHasCode de la clase personalizada. Funciona como un encanto.