¿La interfaz IComparable está desactualizada / “dañina”?

IComparable solo funciona de una manera

Digamos que tienes una Employeeclase. En una vista, desea mostrar todo Employeesordenado por nombre, en otra, por dirección. ¿Cómo vas a lograr eso? No con IComparable, al menos no de ninguna manera idiomática.

IComparable tiene la lógica en el lugar equivocado

La interfaz se usa llamando .Sort(). En una vista que muestra Customerordenado por nombre, no hay ningún código que implique cómo se va a ordenar.
Por otro lado, la Customerclase está asumiendo cómo se va a usar, en este caso, que se usará en una lista ordenada por nombres.

IComparable se usa implícitamente

En comparación con las alternativas, es muy difícil ver dónde se está utilizando la lógica de comparación, o si es que lo está. Asumiendo su IDE estándar y comenzando desde la Customerclase, tendré que

1. Buscar todas las referencias a Customer
2. Encuentra las referencias que se usan en una lista
3. Verifique si esas listas las han .Sort()llamado alguna vez

Lo que probablemente sea peor, si elimina una IComparableimplementación que todavía se está utilizando, no recibirá ningún error o advertencia. Lo único que obtendrá es un comportamiento incorrecto en todos los lugares que eran demasiado oscuros para que usted piense.

Estos problemas combinados, más requisitos cambiantes

La razón por la que llegué a pensar en esto es porque me salió mal. He estado felizmente usando IComparableen mi aplicación durante 2 años. Ahora, los requisitos cambiaron y la cosa necesita ser ordenada de 2 maneras diferentes. Se ha dado cuenta de que no es divertido seguir los pasos descritos en la sección anterior.

La pregunta

Estos problemas me hacen pensar que soy IComparableinferior IComparero .OrderBy(), hasta el punto de no ver ningún caso de uso válido que las alternativas no sirvan mejor.
¿Siempre es mejor usar IComparero LINQ, o hay ventajas / casos de uso que no estoy viendo aquí?

IComparabletiene las restricciones que mencionaste, eso es correcto. Es una interfaz que ya estaba disponible en .NET Framework 1.0, donde esas alternativas funcionales y Linq no estaban disponibles. Entonces, sí, uno podría verlo como un elemento de marco obsoleto que se mantiene principalmente para la compatibilidad con versiones anteriores.

Sin embargo, para muchas estructuras de datos simples, una forma de clasificación es probablemente suficiente o natural. Para estos casos, tener un lugar canónico para implementar la relación de pedido sigue siendo una buena manera de mantener el código SECO, en lugar de repetir siempre la misma lógica en cada llamada a OrderBytodo el lugar.

Usted ha estado "felizmente usando IComparable en su aplicación durante 2 años", como escribió, por lo que me parece que le sirvió durante mucho tiempo. Cuando ahora tiene que validar, cambiar y probar todas las llamadas Sort, también puede ser una señal de que estaba haciendo el mismo tipo de lógica de clasificación en muchos lugares, lo cual no es culpa de IComparable. Entonces, esta podría ser una ocasión para centralizar más de esta lógica en un solo lugar, haciendo que su código sea más SECO.

Estoy de acuerdo con tus sentimientos sobre IComparable

Solo mira los comentarios sobre Array.Sort()

• Cada elemento de la matriz debe implementar la IComparableinterfaz para poder realizar comparaciones con cualquier otro elemento de la matriz. (o se lanza una excepción)
• Si la ordenación no se completa con éxito, los resultados no están definidos.

Probablemente nunca tengamos la motivación, ¡Sin embargo! considere object.Equals()un método en cada objeto que le permite comparar objetos entre sí para ver si son "iguales"

Ya lo tiene allí, pero se le ha encomendado la tarea Array.Sort()de agregar.object.Compare(object)