(J'ai oublié les génériques - les mêmes principes s'appliquent aux formes génériques et non génériques Il n'y a pas d'interface non générative IEquatable, car System.Object a déjà les méthodes appropriées.)
Les objets ne doivent pas être triés pour être utiles en tant que clés IDictionary. Cependant, ils doivent avoir un hachage raisonnable et la mise en œuvre de l'égalité.
Sauf si vous utilisez un dictionnaire qui en fait sortes les clés, vous devriez être plus intéressé par IEqualityComparer<T> et IEquatable<T> - vous n'avez pas besoin d'être en mesure de dire qu'un objet est plus ou moins qu'un autre, juste s'ils sont égaux ou non et quel est le code de hachage d'un objet (d'une manière compatible avec Equals).
La mise en oeuvre est semblable à la mise en oeuvre IEquatableIComparable - cela signifie qu'un objet peut comparer se avec un autre objet du type spécifié (en général, le même type). Bien que n'ait pas pour remplacer Equals (objet) afin d'implémenter IEquatable, il serait fortement recommandé.
La mise en œuvre IEqualityComparer est comme la mise en œuvre IComparer - au lieu de comparer « cet » objet avec un autre, Egaux/méthode de comparaison prend deux valeurs à comparer. Les implémentations de IEqualityComparer/IComparer remplacent rarement object.GetHashCode ou object.Equals, sauf si elles veulent permettre des comparaisons de comparateurs - rarement utiles.
Pour votre troisième point: l'écrasement Equals ne vous oblige certainement pas à surcharger == (vous ne pouvez pas surcharger les opérateurs, seulement les surcharger). Vous pouvez choisir si vous voulez ou non faire cela.