有没有试过从一个集合里面移除一个对象之后，这个集合仍然留有这个对象？世界之大，无奇不有。稍有疏忽，便会导致这种奇怪的现象。现在让我们看看这个“不死”对象究竟是怎么一回事。
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 方法。
在大多数情况下，我们希望比较的并不是对象的引用，而是对象的内容，与此同时，我们又不太可能为了这些小对象劳师动众地实现对象缓存，于是，你就很有可能在类似的代码中邂逅“不死”对象了。
posted on 2007-01-06 22:59 Allen Lee 阅读(146) 评论(7) 编辑 收藏 引用 网摘 所属分类: C#
评论
# re: 当调用 Remove 失效时 [C#] 2007-01-06 23:06 木野狐
这个问题本质上和集合无关，只是对象的判等问题，应该还是比较容易想得到原因的。 回复 更多评论
# re: 当调用 Remove 失效时 [C#] 2007-01-06 23:17 Klesh Wong
同意楼上的,看完头三行代码就基本知道是怎么一回事了.. 回复 更多评论
# re: 当调用 Remove 失效时 [C#] 2007-01-06 23:30 Allen Lee
To 木野狐 and Klesh Wong：
没错，这个问题的本质是对象判等，但你不能说它完全与集合无关。假如这里把 Code #01 的第一行改成：
IList products = new ArrayList();
那么将只有重写 Equals 这个方法才有效了。处理对象判等有很多方法，但不同的集合类可能会采用不同的方法。 回复 更多评论
# re: 当调用 Remove 失效时 [C#] 2007-01-07 00:12 木野狐
@Allen Lee
刚才我用 Reflector 追溯了一下 List<T> 类的判等方法，最终追溯到了
System.Collections.Generic.EqualityComparer<T>
是这个类负责判定对象是否相等。而他有几个子类如下：
ByteEqualityComparer,
GenericEqualityComparer<T>,
NullableEqualityComparer<T>,
ObjectEqualityComparer<T>
上面你提到的如果实现 IEquatable<T> 接口，那么最终会调用到 GenericEqualityComparer<T>, 其判等代码如下：
public override bool Equals(T x, T y)
{
if (x != null)
{
if (y != null)
{
return x.Equals(y);
}
return false;
}
if (y != null)
{
return false;
}
return true;
}
我们可以看到，追根溯源，最终都要调用到 System.Object.Equals 方法的，而这个方法的默认实现就是和 GetHashCode 直接相关。
如果看一下其他几个判等器（ByteEqualityComparer, NullableEqualityComparer<T>, ObjectEqualityComparer<T>），会发现情况没有什么不同。
根据这个分析可以知道，实际上判等和集合类是没有什么联系的，只是集合元素类型自身的比较。并且根据 .NET 的设计规范，Equals 和 == 的语意也应该是一致的。重写 Equals 语意的同时必然也应该重写运算符 ==.
http://www.cnblogs.com/allenlooplee/archive/2007/01/06/613608.html
