3

J'ai une classe A qui implémente IEquatable <>, en utilisant ses champs (disons, Ab et Ac) pour implémenter/redéfinir Equals() et redéfinir GetHashCode(), et tout fonctionne bien, 99% du temps. La classe A fait partie d'une hiérarchie (classe B, C) qui hérite de l'interface D; ils peuvent tous être stockés ensemble dans un dictionnaire de dictionnaire, donc c'est pratique quand ils ont tous leur propre Equals()/GetHashCode() par défaut. Cependant, lors de la construction de A, j'ai parfois besoin de travailler pour obtenir les valeurs de A.b et A.c; Pendant ce temps, je veux stocker une référence à l'instance en construction. Dans ce cas, je ne veux pas utiliser les remplacements par défaut Equals()/GetHashCode() fournis par A. Donc, je pensais à implémenter un ReferenceEqualityComparer, qui est censé forcer l'utilisation de Object's Equals()/GetHashCode() :Comment utiliser Object.GetHashCode() sur un type qui remplace GetHashCode()

private class ReferenceEqualityComparer<T> : IEqualityComparer<T> 
    { 
     #region IEqualityComparer<T> Members 
     public bool Equals(T x, T y) 
     { 
      return System.Object.ReferenceEquals(x, y); 
     } 

     public int GetHashCode(T obj) 
     { 
      // what goes here? I want to do something like System.Object.GetHashCode(obj); 
     } 
     #endregion 
    } 

La question est, puisque A l'emporte sur Object.GetHashCode(), comment puis-je (hors A) appeler Object.GetHashCode() pour une instance de A? Une solution serait bien sûr de ne pas implémenter IEquatable <> et de toujours fournir un IEqualityComparer <> à tout dictionnaire que je crée, mais j'espère une réponse différente.

Merci

+2

Vous vous creuser un trou assez profond. En sortir avec IEqualityComparer <>. –

Répondre

-1

Appel de mise en œuvre de base du CLR via Interop: Default implementation for Object.GetHashCode()

+0

Le lien est intéressant à des fins académiques, mais vous devriez vraiment utiliser 'RuntimeHelpers.GetHashCode()' à la place. –

+0

Vrai, je ne savais pas à ce sujet. Il appelle juste exactement la même méthode interop sous-jacente, donc il n'y a pas de différence fonctionnelle (mais ouais: vous devriez utiliser l'API publiée au cas où il changerait ...) – piers7

Questions connexes