IComparable接口是否过时/“有害”？
IComparable 仅以一种方式工作 假设您有一Employee堂课。在一个视图中，您要显示所有Employees按名称排序的视图-在另一个视图中按地址显示。您将如何实现？不使用IComparable，至少不是以任何惯用的方式。 IComparable 逻辑错误 通过调用使用该接口.Sort()。在显示Customer按名称排序的视图中，根本没有代码暗示如何进行排序。 另一方面，Customer该类假设如何使用它-在这种情况下，它将在按名称排序的列表中使用。 IComparable 隐式使用 与替代方案相比，很难看到在何处使用了比较逻辑，或者根本看不到。假设您使用标准IDE，并从Customer课堂开始，我将不得不 搜索所有引用 Customer 查找列表中使用的那些引用 检查这些列表是否曾经拜访过.Sort()它们 更糟的是，如果删除IComparable仍在使用的实现，则不会收到任何错误或警告。您将得到的唯一一件事就是在所有难以理解的地方出现错误的行为。 这些问题加在一起，加上需求不断变化 我之所以开始考虑这一点，是因为它对我来说是错的。我已经IComparable在我的应用程序中愉快地使用了两年了。现在，需求发生了变化，事物需要以两种不同的方式进行分类。已经注意到，遍历上一节中描述的步骤并不是一件有趣的事情。 问题 这些问题使我认为IComparable不如IComparer或.OrderBy()，以至于看不到任何其他替代方案无法更好地解决的有效用例。 使用IComparer或LINQ 总是更好吗，还是这里没有我看到的优点/用例？