Allen Lee's Magic

这里没有答案，顶多给你几个值得一试的猜想。

当调用 Remove 失效时 [C#]

当调用 Remove 失效时 [C#]

 

Written by Allen Lee

 

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

 

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 阅读(2551) 评论(17)  编辑 收藏 网摘 所属分类: C#

评论

#1楼 2007-01-06 23:06 木野狐      

这个问题本质上和集合无关，只是对象的判等问题，应该还是比较容易想得到原因的。   回复  引用  查看    

#2楼 2007-01-06 23:17 Klesh Wong      

同意楼上的,看完头三行代码就基本知道是怎么一回事了..   回复  引用  查看    

#3楼[楼主] 2007-01-06 23:30 Allen Lee      

To 木野狐 and Klesh Wong：

没错，这个问题的本质是对象判等，但你不能说它完全与集合无关。假如这里把 Code #01 的第一行改成：

IList products = new ArrayList();

那么将只有重写 Equals 这个方法才有效了。处理对象判等有很多方法，但不同的集合类可能会采用不同的方法。   回复  引用  查看    

#4楼 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 语意的同时必然也应该重写运算符 ==.   回复  引用  查看    

#5楼 2007-01-07 00:17 木野狐      

"假如这里把 Code #01 的第一行改成：

IList products = new ArrayList();

那么将只有重写 Equals 这个方法才有效了。"

＝＝＝
这个只是因为 ArrayList 是普通类，而 List<T> 是泛型类。但最终还是会调用到上面这几个 EqualityComparer. 进而调用 Equals 方法。   回复  引用  查看    

#6楼 2007-01-07 10:31 wuChang      

class Product要override 掉GetHashCode 方法，
  回复  引用  查看    

#7楼[楼主] 2007-01-07 10:42 Allen Lee      

To 木野狐：

你说的没错，追根溯源，上面这些判等方法都会回归到 Equals，这很明显是由于 Equals 是 .NET 整个生命周期里面唯一贯穿始终的判等方法，无论是最初的 1.0 还是最新的 3.0。

然而，EqualityComparer 并不是一定要和 Equals 关联在一起，举个例子，假如我使用一个支持自定义 EqualityComparer 的集合类（例如 Dictionary<T>，它的一个构造函数可以指定你自己的 EqualityComparer），而实体类（例如 Product）本身没有重写 Equals 和 GetHashCode 方法，但由于某些原因不能或不允许修改源代码，这样，我们唯一可以做的就是通过 EqualityComparer 来扩展这部分功能了（而此时你就不能在把 EqualityComparer 和 Equals 关联在一起了），而这其实就是遵循了“开闭原则”（OCP），当然，这种扩展性只有 2.0 以上的 .NET 才支持。   回复  引用  查看    

#8楼 2007-01-07 14:11 木野狐      

@Allen Lee
是的，我开始也没有考虑到这种可能性。
不过现在考察一下 Dictionary<TKey, TValue>, 从理论上的确是有这个扩展的可能。
但是我始终觉得判等操作应该是 Product 这个类的职责，如果说一个类的对象，被加到字典里时，通过实现自己的 IEqualityComparer 来实现不同的判等逻辑；而当它在列表里的时候，却不能在默认情形下表现出相同的行为，未免会让用户代码感觉疑惑。

所以我觉得这个做法虽然可行，但也只能是作为一种不得已而为之的策略来使用的。只要可能，还是重写 Equals 或 GetHashCode 方法来的更好些。

anyway, 理越辩越明了, Thanks :-)
  回复  引用  查看    

#9楼[楼主] 2007-01-07 14:28 Allen Lee      

To 木野狐：

这当然，最简单直接的方法其实就是把判等逻辑通过 Equals 和 GetHashCode 内嵌到实体类里面。但如果实体类是以 DLL 的形式发布的，并且开发它们的时候并没有料想到逻辑判等的需要，那么从外部进行这种扩展就非常有必要了。

Anyway, it is interesting to discuss with you. Thanks.   回复  引用  查看    

#10楼 2007-01-07 20:27 A.Z[匿名][未注册用户]

对象编成的基础啊，如此眩晕可不好。
第一要了解到什么是标准的行为，第二是要努力让自己的行为标准化。   回复  引用    

#11楼 2007-01-13 01:05 yinh      

能通过这个例子了解到一些更多，更深层次的知识固然是好。但正如上面A.Z所说的，一些基础的东西不能丢。
有些初学者在看jeffery richter在applied中所写的对象一章时提到的要覆写equals和gethashcode方法时可能会不太理解，或者没有感性的认识。随着不断的深入，比如遇到今天的问题，就会对这些基本概念有所理解了   回复  引用  查看    

#12楼 2007-01-18 21:54 C#爱好[未注册用户]

用下法的方法是不是就可以避免上面遇到的问题了呢!这说明一个问题,一种写代码的习惯也是一样很重要的事情.不过此处研究Equals的方法才是根本问题!

IList products = new List<Product>();
Product product = GetProduct("1412");
products.Add(product );
products.Remove(product );   回复  引用    

#13楼 2007-01-23 12:34 Johnson Cao      

看完楼上的.
我想应该重写Remove方法.
一般我都提供RemoveById
和Remove方法.   回复  引用  查看    

#14楼 2007-01-23 12:35 Johnson Cao      

这不是不死的问题.是编码质量的问题.   回复  引用  查看    

#15楼 2007-06-24 22:55 带头大哥[未注册用户]

所以才要我们重写Equal啊....

public override bool Equals(object obj)
{
if(this.GetType() == typeof(Product)){
return true;
}
return false;
}   回复  引用    

#16楼 2008-07-08 13:16 王弈博      

不能用字典算法吗？   回复  引用  查看    

#17楼[楼主] 2008-07-15 18:41 Allen Lee      

@王弈博
可以的，当时写这篇文章的时候只是就事论事而已。   回复  引用  查看    




发表评论

昵称： [登录] [注册]

主页：

邮箱：(仅博主可见)

评论内容：

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 613608




相关文章:

相关链接: