Equal override

Dlaczego nie lubię override Equal? Wszystko jest dla ludzi. Pewnie się nawet zbłaźnię tą opowieścią :]
Ostatnio poszukiwałam błędu w kodzie, w którym przeciążone były funkcje Equals (o czym dowiedziałam się po znacznym czasie spędzonym z debuggerem), a czasem także ==. Błąd okazał się dość paskudny bo był nieprzewidywalny. Problem był po dodaniu elementu do kolekcji - nagle zwracane były nieprawidłowe elementy z kolekcji.
Na pierwszy rzut oka Equals wyglądał dobrze, zgodnie z zasadami zalecanymi przez msdn. Dodatkowo sprawdzana była zgodność referencji mniej więcej w tym tonie (pominęłam kwestie nulli):

    public class Person
    {
        private long _ID;
        public long ID
        { get { return _ID; } set { _ID = value; } }

        private string _Name;
        public string Name { get { return _Name; } set { _Name = value; } }

        public override bool Equals(object obj)
        {
            //obie alternatywy działają równie dobrze
            if (base.Equals(obj))//Object.ReferenceEquals(this, obj))
            {
                return true;
            }
            else
            {
                return this.Name == (obj as Person).Name;
            }
        }
    }

Wszystko będzie dobrze jeśli zadbamy o unikalność Name, w kodzie który poprawiałam unikalność nie była zachowana, dlatego wyniki były niezgodne z oczekiwaniami dla nowych elementów listy (w przeciwnym przypadku działał bazowy Equal porównujący referencje).

//troche danych testowych, ID zgadza się z indexem w liście.            
            Person expectedOla = new Person() { ID = 3, Name = "Ola" };
            Person expectedAla = new Person() { ID = 2,Name = "Ala" };
            List p =
            new List()
            {
                new Person() { ID = 0,Name = "Ala" },
                new Person() { ID = 1,Name = "Ola" },
                expectedAla,
                expectedOla
            };
var iola = p.IndexOf(expectedOla)
//iola == 1

Całkiem oczywisty wynik skoro porównujemy Name, no ale przecież porównujemy także referencje! Jednak kiedy referencja się nie zgadza wracamy do porównania Name. IndexOf jak pisze msdn działa od początku listy porównując każdy element - więc znajduje Olę pod 1. Tak naprawdę p.IndexOf(new Person()) po dekompilacji jakimś sprytnym narzędziem daje:

[System.Runtime.TargetedPatchingOptOutAttribute(@"Performance critical to inline across NGen image boundaries")]
public virtual int IndexOf(T item) {
  return Array.IndexOf(this._items, item, 0, this._size);
}

Na pewno używając jakieś funkcji warto było by dla przypomnienia sięgnąć do MSDNa. Ja w większości przypadków opieram się niestety na intelisens (choć ostatnio musiało się to zmienić) - mimo że w większości przypadków to wystarcza, jednak tam nie znajdziemy informacji że IndexOf bazuje na funkcji Equals, a jeśli jest ona przeciążona bazuje na jej bieżącym przeciążeniu.

Koniec końców musimy być uważni pisząc kod, a potem go naprawiając. Nie chodzi o to żeby fajnie coś się samo rzutowało, porównywało i inne bajery. Owszem jest to fajne, nawet w odkrywczym debugowaniu, jednak termin nie czeka na 'fajne. A nowa osoba w projekcie niekoniecznie będzie wiedzieć o jakimś przeciążeniu i mogą generować się błędy (oczywiście że błędy tak jak bałagan czy wiry w zlewie robią się same :]) bardzo pracochłonne w namierzeniu. Osobiście jestem za jakąś inną funkcją może CompareTo? ale na pewno taką którą łatwo się refaktoryzuje, wyszukuje i zmienia (a to przecież robi się ciągle i to często w kółko w zależności od klienta) przez cały system nie zastanawiając się czy dodatkowo jakaś funkcja .Netowa na niej nie bazuje.

Jednak nie jestem absolutnym przeciwnikiem. Bardzo przydatne jest przeciążenie Equals dla np słowników - obiektów w miarę rzadko zmieniających swoje wartości i na pewno rzadko zmieniających strukturę (słowniki zazwyczaj nie zmieniają się wiele przez całe życie projektu, przynajmniej tak wynika z mojego doświadczenia :] ). Przeciążenie Equals zagwarantuje nam możliwość łatwiejszego używania takich obiektów np w ComboBoxach.
Wszystko jest dla ludzi, ale - jak jeże - ostrożnie