Question

我正在开发一个带有几个类的简单应用程序。这一切都是在我想在List<Car>上使用Remove方法时开始的。此方法要求您覆盖Equals类型的GetHashCode和Car方法。在这种情况下，我决定在Car类上实现ID属性。这样，我的Equals方法只检查ID相等，我的GetHashCode方法返回base.GetHashCode()。

这是一个很好的方法，还是为一个过于沉重的小班级实施GUID？没有我上面解释的原因，就没有必要。此Car类型唯一性的唯一要求是它在其所属的List<T>集合中是唯一的。但添加GUID属性似乎是围绕GetHashCode混乱的最快方式。顺便说一句，我的Car类型没有int属性。

Answer 1

如果没有我上面解释的原因，就没有必要。

如果你的班级逻辑没有ID，那么为了平等而包含它肯定是奇怪的。

例如，如果你有两个除了ID之外的所有具有相同属性的实例，它们真的不相等吗？如果是，则应该使用Equals / GetHashCode的默认实现，该实现使用引用标识进行相等。如果您使用具有相同ID的两个对象，则只需使用对同一对象的两个引用。

这完全取决于上下文，而你没有给出太多 - 但为了平等而添加一个ID 只是是一种设计气味。

Answer 2

不要实现Equals和GetHashCode，只需使用RemoveAll：

myList.RemoveAll(x => x.ID == myCar.ID);

这允许您指定一个谓词来指示应该删除哪些项目（您只删除一个项目并不重要）。

以您描述的方式实施Equals和GetHashCode会让我觉得非常笨拙 - 如果您的Equals实施返回true，那么您的GetHashCode方法 needs 返回相同的值，以便将这两个对象放在哈希表中的同一个桶中。您的实现（据我所知）与此条件不匹配，因为基本GetHashCode实现几乎肯定会为两个Car实例返回不同的值，无论它们是否具有相同的ID

实施Equals和GetHashCode并非完全无足轻重，如果有替代方案，我通常会避免这样做。如果你真的想这样做，那么看看这些资源：

哈希码也不是GUIDs

何时为类使用GUID

2 个答案: