实现IEquatable <t>，其中T是接口</t>

Question

我有一个域模型，可以用以下代码表示。

IMyInterface

ClassA : IMyInterface

ClassB : IMyInterface

我想要的是以这样一种方式实现IEquatable，即我可以编写类似的代码。

if(dynamicallyCreatedInstanceOfClassA == dynamicallyCreatedinstanceOfClassB)
{
  // Do something relevant
}

我的第一个倾向是让IMyInterface实现IEquatable，但当然我实际上无法在IMyInterface中实现。我必须在ClassA和ClassB中这样做。这个解决方案让我觉得错误的是，ClassA和ClassB中IEquatable的实现将完全相同，行相同。有一种优雅的方式来实现这一目标吗？当ClassC出现时，我不想复制和过去50行重复的IEquatable代码。

我考虑使用抽象基类而不是接口，但在这种情况下，IMyInterface实际上只描述了类将执行的操作而不是类。 ClassA和ClassB不共享许多相似之处，除非它们都可以执行IMyInterface合同中的操作。

任何见解都很有帮助，谢谢您的时间。

Answer 1

您可以在单独的类中实现IEquatable<T>，而不是实现IEqualityComparer<T>吗？在大多数情况下，你对等式感兴趣，你可以指定一个比较器，我怀疑它会更清洁。

Answer 2

根据您的问题，您似乎知道Equals算法将是什么，并且ClassA和ClassB将完全相同。为什么不这样做

1. 定义IMyInterface以继承自IEquatable<IMyInterface>
2. 定义一个抽象基类MyInterfaceBase，它实现IMyInterface并具有IEquatable<IMyInterface>实现
3. 让ClassA和ClassB派生自MyInterfaceBase

Answer 3

如果IEquatable<T>包含GetHashcode()成员，则可能为该类型定义与Object.Equals不同的有意义语义（例如“如果只查看存在的特征）在T中，对象被认为是相同的“）。但是，由于它没有太多理由实现IEquatable<T>，除非在不增加任何古怪语义的情况下它可以提高性能。在实践中，这意味着IEquatable<T>应该仅由T本身实现（如果T是密封的类或结构），或者根本不实现（如果T是{{1}}可继承的，或者性能上的好处是不值得的。）

Answer 4

我认为如果接口无法转换为抽象类，那么将两个实现的类直接或自动地相互比较就没那么有意义了。这意味着在每个类上实现自定义比较将是最佳选择。我确信你可以以某种方式重构比较代码，以便以后更容易地改变它。