（转载）当调用 Remove 失效时 [C#]

有没有试过从一个集合里面移除一个对象之后，这个集合仍然留有这个对象？世界之大，无奇不有。稍有疏忽，便会导致这种奇怪的现象。现在让我们看看这个“不死”对象究竟是怎么一回事。

 

1、“不死”对象现身

这个问题起初是我一个同事提出的，为了重现“不死”对象，现把代码简化如下：

// Code #01

IList products = new List<Product>();
products.Add(GetProduct("1412"));
products.Remove(GetProduct("1412"));

其中 Product 类代码如下：

// Code #02

class Product
{
    public Product(string id)
    {
        m_ID = id;
    }

    private string m_ID;
    public string ID
    {
        get { return m_ID; }
    }

    public override string ToString()
    {
        return "ID: " + m_ID;
    }
}

而 GetProduct 方法则根据传入的 ID 从数据库读取数据并返回，它的签名如下：

// Code #03

public static Product GetProduct(string id);

要想知道编号为 1412 的对象是否从 products 中移除，只需在 Code #01 的最后加上这样一行：

// Code #04

Console.WriteLine(products.Count);

 

2、一不小心掉进陷阱

不知道你有没有查看 SDK 的习惯，其实 SDK 里面蕴藏着很多对我们解决问题有启发作用的信息的。现在让我们看看 SDK 里面能否找到什么蛛丝马迹。

由于 products 的真身是 List<T>，所以我们有必要看看 List<T> 是如何实现 IList.Remove 的：

This method determines equality using the default equality comparer EqualityComparer.Default for T, the type of values in the list.

原来，List<T> 在 IList.Remove 中使用 EqualityComparer.Default 来判断两个对象是否相等。那么 EqualityComparer.Default 又是如何得知两个对象是否相等呢？

The Default property checks whether type T implements the System.IEquatable generic interface and if so returns an EqualityComparer that uses that implementation. Otherwise it returns an EqualityComparer that uses the overrides of Object.Equals and Object.GetHashCode provided by T.

把上面这段话结合 Code #02 来看，我们可以发现 List<T> 中的 IList.Remove 判断两个 Product 对象是否相等的方法是从 Object 根类继承下来的 Equals 和 GetHashCode 方法，即比较两个对象的引用是否指向同一个对象。

由于 GetProduct 方法每次返回的都是一个新的对象（暂时让我们忘记对象缓存这家伙），于是就导致了集合里面出现“不死”对象。

 

3、不要被同一颗子弹打中两次

“不要被同一颗子弹打中两次”原意是指同一个错误不要两次犯，这句话暗含着对两个表示错误的对象进行逻辑上的判等，就像上面需要判断两个 Product 的对象在逻辑上是否相等那样。

至此，我们也知道了令 Remove 重新生效的两个可选办法是：

• 让 Product 类实现 IEquatable<T> 接口；
• 为 Product 类重写 Equals 和 GetHashCode 方法。

在大多数情况下，我们希望比较的并不是对象的引用，而是对象的内容，与此同时，我们又不太可能为了这些小对象劳师动众地实现对象缓存，于是，你就很有可能在类似的代码中邂逅“不死”对象了。