A interface IComparable está desatualizada / "prejudicial"?

IComparable só funciona de uma maneira

Digamos que você tenha uma Employeeaula. Em uma exibição, você deseja mostrar todas as Employeesordenadas por nome - em outra, por endereço. Como você vai conseguir isso? Não com IComparable, pelo menos não de maneira idiomática.

IComparable tem a lógica no lugar errado

A interface é usada chamando .Sort(). Em uma exibição que mostra Customerclassificada por nome, não há nenhum código que implique como será classificado.
Por outro lado, a Customerclasse está assumindo como será usada - nesse caso, que será usada em uma lista classificada por nomes.

IComparable é usado implicitamente

Em comparação com as alternativas, é muito difícil ver onde a lógica de comparação está sendo usada - ou se é que existe. Supondo que seu IDE padrão e a partir da Customerclasse, terei que

1. Pesquise todas as referências a Customer
2. Encontre as referências usadas em uma lista
3. Verifique se essas listas já os .Sort()chamaram

O que é provavelmente pior, se você remover uma IComparableimplementação que ainda está sendo usada, você não receberá nenhum erro ou aviso. A única coisa que você terá é o comportamento errado em todos os lugares que eram muito obscuros para você pensar.

Essas questões combinadas, além de requisitos variáveis

O motivo pelo qual eu vim a pensar sobre isso é porque deu errado para mim. Felizmente, uso IComparablemeu aplicativo há 2 anos. Agora, os requisitos foram alterados e a coisa precisa ser classificada de duas maneiras diferentes. Percebeu que não é divertido seguir as etapas descritas na seção anterior.

A questão

Esses problemas me fazem pensar IComparablecomo inferior a IComparerou .OrderBy(), a ponto de não ver nenhum caso de uso válido que não seria melhor atendido pelas alternativas.
É sempre melhor usar IComparerou LINQ, ou existem vantagens / casos de uso que não estou vendo aqui?

IComparabletem as restrições que você mencionou, isso está correto. É uma interface que já estava disponível no .NET Framework 1.0, onde essas alternativas funcionais e o Linq não estavam disponíveis. Então, sim, pode-se vê-lo como um elemento de estrutura desatualizado que é mantido principalmente para compatibilidade com versões anteriores.

No entanto, para muitas estruturas simples de dados, uma maneira de classificar é provavelmente suficiente ou natural. Nesses casos, ter um local canônico para implementar o relacionamento do pedido ainda é uma boa maneira de manter o código DRY, em vez de sempre repetir a mesma lógica em todas as chamadas para OrderBytodo o local.

Você está "felizmente usando o IComparable em seu aplicativo há 2 anos", como escreveu, portanto, parece-me que serviu bem por um longo tempo. Quando você agora precisa validar, alterar e testar todas as chamadas Sort, também pode ser um sinal de que você estava fazendo o mesmo tipo de lógica de classificação em muitos lugares, o que não é culpa dele IComparable. Portanto, essa pode ser uma ocasião para centralizar mais essa lógica em um só lugar, tornando seu código mais SECO.

Eu concordo com seus sentimentos sobre IComparable

Basta olhar para as observações em Array.Sort()

• Cada elemento da matriz deve implementar a IComparableinterface para poder comparar com todos os outros elementos da matriz. (ou exceção é lançada)
• Se a classificação não for concluída com êxito, os resultados serão indefinidos.

Provavelmente nunca iremos agora a motivação, no entanto! considere object.Equals()um método para cada objeto que permita comparar objetos entre si para ver se eles são "iguais"

Você já o possui, mas recebeu a tarefa de adicionar. Array.Sort()Você pode adicionarobject.Compare(object)