Supposons que j'ai une classe T que je souhaite utiliser comme clé dans une collection Dictionary<T,U>.Que faut-il faire pour utiliser la valeur d'un type de référence en tant que clé de dictionnaire?
Que dois-je implémenter dans T afin que ces clés soient basées sur des valeurs de T plutôt que des références T? J'espere que c'est juste GetHashCode()
Vous devez implémenter GetHashCode() et Equals().
Dictionnaire est un Hashtable en dessous des couvertures, de sorte que vous pouvez lire ceci: Pitfalls Of Equals/GetHashCode – How Does A Hash Table Work?
Vous devez passer outre Equals(object obj). Il est toujours attendu que vous implémentez GetHashCode lorsque vous modifiez Equals. Lisez ceci article sur MSDN.
Si vous ne passez pas IEqualityComparer<T> dans le constructeur dictionnaire, il utilisera EqualityComparer<T>.Default qui est défini par MSDN comme:
Les contrôles de propriété par défaut si type T implémente le System.IEquatable (de T interface et, le cas échéant, renvoie un EqualityComparer (Of T) que utilise cette implémentation. Dans le cas contraire, il retourne un EqualityComparer (Of T) qui utilise les redéfinitions Object.Equals et Object.GetHashCode fournies par T.
Donc, la mise en œuvre IEquatable<T> serait mon choix (si vous le mettre en œuvre, il est également logique pour remplacer Equals et GetHashCode de toute façon).
Soit et mettre en œuvre EqualsGetHashCodeou créer un IEqualityComparer<T> approprié qui a la bonne forme d'égalité correspondant à votre carte. J'aime plutôt la route IEqualityComparer<T>: dans la plupart des cas, il n'y a pas une seule forme d'égalité à droite: vous voulez traiter les objets de manière différente selon la situation. Dans ce cas, un comparateur d'égalité personnalisé est exactement ce dont vous avez besoin. Bien sûr, s'il est une opération d'égalité naturelle, il est logique d'implémenter IEquatable<T> dans le type lui-même ... si vous le pouvez. (Un autre avantage de IEqualityComparer<T> est que vous pouvez l'implémenter pour les types sur lesquels vous n'avez aucun contrôle.)
Je ne recommanderais pas d'avoir un type héritable implémentable IEquatable, car de mauvaises choses se produiront si un type dérivé substitue Object.Equals (Object) et/ou Object.GetHashCode (Object) et l'implémentation de IEquatable n'appelle pas ces remplacements; puisque lancer vers Object pour appeler ces overrides annulerait tout avantage obtenu en utilisant l'interface générique, il n'y a vraiment aucun intérêt à l'implémenter. –
supercat