L'interfaccia IComparable è obsoleta / "dannosa"?

IComparable funziona solo in un modo

Diciamo che hai una Employeelezione. In una vista, vuoi mostrare tutto Employeesordinato per nome - in un'altra, per indirizzo. Come lo farai? Non con IComparable, almeno non in alcun modo idiomatico.

IComparable ha la logica nel posto sbagliato

L'interfaccia viene utilizzata chiamando .Sort(). In una vista mostrata Customerordinata per nome, non esiste alcun codice che implichi il modo in cui verrà ordinata.
D'altra parte, la Customerclasse presuppone come verrà utilizzata, in questo caso verrà utilizzata in un elenco ordinato per nome.

IComparable è usato implicitamente

In confronto con le alternative, è molto difficile vedere dove viene utilizzata la logica di confronto - o se non del tutto. Supponendo il tuo IDE standard e partendo dalla Customerclasse, dovrò

1. Cerca tutti i riferimenti a Customer
2. Trova i riferimenti utilizzati in un elenco
3. Controlla se quegli elenchi .Sort()li hanno mai chiamati

Quel che è probabilmente peggio, se si rimuove IComparableun'implementazione ancora in uso, non si ottiene alcun errore o avviso. L'unica cosa che otterrai è un comportamento sbagliato in tutti i luoghi che erano troppo oscuri per farti pensare.

Questi problemi combinati, oltre a cambiare i requisiti

La vera ragione per cui sono venuto a pensarci è perché è andato storto per me. Uso felicemente la IComparablemia candidatura da 2 anni. Ora, i requisiti sono cambiati e la cosa deve essere ordinata in 2 modi diversi. Ha notato che non è divertente passare attraverso i passaggi descritti nella sezione precedente.

La domanda

Questi problemi mi fanno pensare IComparableche sia inferiore IComparero .OrderBy(), al punto da non vedere alcun caso d'uso valido che non sarebbe servito meglio dalle alternative.
È sempre meglio usare IComparero LINQ o ci sono vantaggi / casi d'uso che non vedo qui?

IComparableha le restrizioni che hai citato, è corretto. È un'interfaccia che era già disponibile in .NET Framework 1.0, dove quelle alternative funzionali e Linq non erano disponibili. Quindi sì, si potrebbe vederlo come un elemento framework obsoleto, che viene mantenuto principalmente per compatibilità con le versioni precedenti.

Tuttavia, per molte semplici strutture di dati, un modo di ordinare è probabilmente sufficiente o naturale. In questi casi, avere un posto canonico per implementare la relazione d'ordine è ancora un buon modo per mantenere il codice DRY, invece di ripetere sempre la stessa logica in ogni chiamata a OrderBytutto il luogo.

"Usi felicemente IComparable nella tua applicazione da 2 anni", come hai scritto, quindi mi sembra che ti sia servito bene per molto tempo. Quando ora devi convalidare, modificare e testare tutte le chiamate Sort, potrebbe anche essere un segno che stavi facendo lo stesso tipo di logica di ordinamento in molti punti, di cui non è colpa IComparable. Quindi questa potrebbe essere un'occasione per centralizzare più di questa logica in un unico posto, rendendo il tuo codice più ASCIUTTO.

Sono d'accordo con i tuoi sentimenti in merito IComparable

Guarda le osservazioni su Array.Sort()

• Ogni elemento dell'array deve implementare l' IComparableinterfaccia per poter essere confrontato con ogni altro elemento dell'array. (o viene generata un'eccezione)
• Se l'ordinamento non viene completato correttamente, i risultati non sono definiti.

Probabilmente non avremo mai ora la motivazione, tuttavia! considera object.Equals()un metodo su ogni oggetto che ti consente di confrontare gli oggetti tra loro per vedere se sono "uguali"

Lo hai già lì, ma ti è stato assegnato il compito di aggiungere Array.Sort()che potresti voler aggiungereobject.Compare(object)