Czy interfejs IComparable jest przestarzały / „szkodliwy”?

IComparable działa tylko w jedną stronę

Powiedzmy, że masz Employeeklasę. W jednym widoku chcesz pokazać wszystkie Employeesposortowane według nazwy - w innym według adresu. Jak zamierzasz to osiągnąć? Nie z IComparable, przynajmniej nie w idiomatyczny sposób.

IComparable ma logikę w niewłaściwym miejscu

Interfejs jest używany przez wywołanie .Sort(). W widoku pokazującym Customerposortowane według nazwy, w ogóle nie ma kodu, który wskazywałby , jak będzie sortowany.
Z drugiej strony Customerklasa zakłada, w jaki sposób będzie używana - w tym przypadku będzie używana na liście posortowanej według nazw.

IComparable jest używany niejawnie

W porównaniu z alternatywami bardzo trudno jest zobaczyć, gdzie stosowana jest logika porównawcza - lub w ogóle. Zakładając standardowe IDE i zaczynając od Customerklasy, będę musiał

1. Wyszukaj wszystkie odniesienia do Customer
2. Znajdź odniesienia, które są używane na liście
3. Sprawdź, czy te listy kiedykolwiek .Sort()do nich dzwoniły

Co gorsza, jeśli usuniesz IComparableimplementację, która jest nadal używana, nie pojawi się błąd ani ostrzeżenie. Jedyne, co dostaniesz, to złe zachowanie we wszystkich miejscach, które były zbyt niejasne, abyś o tym pomyślał.

Te problemy łącznie, a także zmieniające się wymagania

Powodem, dla którego pomyślałem o tym, jest to, że poszło mi nie tak. Z radością korzystam IComparablez aplikacji od 2 lat. Teraz wymagania się zmieniły i rzecz musi zostać posortowana na 2 różne sposoby. Zauważyłem, że nie jest fajnie przechodzić przez kroki opisane w poprzedniej sekcji.

Pytanie

Te problemy sprawiają, że uważam się IComparableza gorszy IComparerlub .OrderBy()do tego stopnia, że ​​nie widzę żadnego ważnego przypadku użycia, który nie byłby lepiej obsługiwany przez alternatywy.
Czy zawsze lepiej jest używać IComparerlub LINQ, czy też są zalety / przypadki użycia, których tu nie widzę?

IComparablema wspomniane ograniczenia, które są poprawne. Jest to interfejs, który był już dostępny w .NET Framework 1.0, w którym te funkcjonalne alternatywy i Linq nie były dostępne. Tak, można by uznać, że jest to przestarzały element frameworka, który jest głównie przechowywany w celu zachowania kompatybilności wstecznej.

Jednak w przypadku wielu prostych struktur danych jeden sposób sortowania jest prawdopodobnie wystarczający lub naturalny. W takich przypadkach posiadanie jednego kanonicznego miejsca do implementacji relacji zamówienia jest nadal dobrym sposobem na zachowanie kodu DRY, zamiast zawsze powtarzania tej samej logiki przy każdym wywołaniu do OrderBycałego miejsca.

Jak pisałeś, „z radością używasz IComparable w swojej aplikacji od 2 lat”, więc wydaje mi się, że dobrze ci to służyło przez długi czas. Kiedy teraz musisz zweryfikować, zmienić i przetestować wszystkie połączenia z Sort, może to być również znak, że robiłeś ten sam rodzaj logiki sortowania w wielu miejscach, co nie jest winą IComparable. Może to być okazja do scentralizowania większej ilości tej logiki w jednym miejscu, dzięki czemu Twój kod będzie bardziej SUCHY.

Zgadzam się z twoimi sentymentami IComparable

Spójrz tylko na uwagi Array.Sort()

• Każdy element tablicy musi implementować IComparableinterfejs, aby mógł być porównywany z każdym innym elementem tablicy. (lub zgłoszony wyjątek)
• Jeśli sortowanie nie zakończy się pomyślnie, wyniki są niezdefiniowane.

Prawdopodobnie nigdy nie będziemy mieć motywacji, jednak! rozważ object.Equals()metodę na każdym obiekcie, która pozwala porównywać obiekty ze sobą, aby sprawdzić, czy są one „takie same”

Masz już to, ale powierzono Array.Sort()ci zadanie dodania, które możesz chcieć dodaćobject.Compare(object)