我应该实现 IEquatable 还是 IComparable？答案

【问题标题】：Should I implement IEquatable, or IComparable?我应该实现 IEquatable 还是 IComparable？
【发布时间】：2014-01-18 00:29:26
【问题描述】：

我有课。这个类要表示的事物是这样的，我们可以说这些事物是彼此相等的，我们也可以想出一个方案来对它们进行排名用于比较。

然而，很少有人觉得需要对这些事物进行排名，但人们经常需要检查两个这样的事物是否相等。

所以，我可以为我的班级实现IEquatable 以及IComparable。虽然IComparable 提供了一些额外的功能，但不太可能有人会关心这些额外的功能。两者似乎都没有提供明显的优势，无论是逻辑上还是功能上。

我应该实现哪个接口，IEquatable、IComparable，还是两者都实现？为什么？（我特别想知道任一接口对框架范围的影响）

This question 类似，但答案只说明了显而易见的，这对我没有帮助。

如果您想知道，该类旨在表示一个核苷酸。核苷酸可以很容易地等同起来，但也可以进行比较（例如按字母顺序）。

【问题讨论】：

是否有可能需要对它们进行排序？我知道您说过这不太可能，但如果您要将课程交给其他人，您能想出他们需要排序的原因吗？
我敢肯定，有可能想出一个人为的场景，其中可能需要按字母顺序对它们进行排序（以产生具有良好格式的人类可读输出），或者可能通过某些生化特性对它们进行排序（如质量）。但这是人为的，如果我要实现IComparable，我将不得不为很少使用的方法编写文档（没有它，该方法将毫无用处）。

标签： c# .net

【解决方案1】：

我肯定会实现IEquatable<T>，但现在跳过IComparable/IComparable<T>。

正如您所说，没有一种方法可以比较核苷酸。有人可能需要按字母顺序比较它们，有人可能需要另一种方式来对它们进行排序。我宁愿提供IComparer<Nucleotide>的不同实现来实现IComparable/IComparable<T>本身。

【讨论】：

没有非泛型IEquatable，就好像它会匹配Equals()覆盖所有对象一样。也就是说，当实现IEquatable<T> 时，必须始终适当地覆盖Equals() 和GetHashCode()，所以你的观点成立。

【解决方案2】：

这主要是基于意见，但如果可比性不明显（如数量），我不会实施IComparable。例如，如果有人想对核苷酸进行排序，它可以提供自己的IComparer 实现。作为图书馆作者，我会提供一组可能的IComparers，例如按照您所说的按字母顺序对它们进行排序。

【讨论】：

【解决方案3】：

如果对象本质上具有可比性，那么我会做额外的工作并在IEquatable<T> 之上实现IComparable<T>。作为该类型的作者，您处于提供正确实现的最佳位置。将其留给其他开发人员来实现会增加发生以下情况的机会

【讨论】：

【解决方案4】：

您应该实现能够满足您现在所需的接口。如果你后来发现IComparable 是你需要的东西，那么就实现它。

很难决定将来要进行多少校对。但是当添加额外的未来功能相对简单时，我总是选择不这样做。你可能会发现你永远不需要IComparable，即使它是一个微小的添加，它仍然需要维护和考虑。

【讨论】：