当调用 Remove 失效时 [C#]

当调用 Remove 失效时 [C#
]




Written by Allen Lee




有没有试过从一个集合里面移除一个对象以后,这个集合仍然留有这个对象?世界之大,无奇不有。稍有疏忽,便会致使这种奇怪的现象。如今让咱们看看这个“不死”对象到底是怎么一回事。

一、“不死”对象现身


这个问题起初是我一个同事提出的,为了重现“不死”对象,现把代码简化以下:
//Code#01 IListproducts=newListProduct(); products.Add(GetProduct("1412")); products.Remove(GetProduct("1412"));
其中 Product 类代码以下:
//Code#02 classProduct { publicProduct(stringid) { m_ID=id; } privatestringm_ID; publicstringID { get {returnm_ID;} } publicoverridestringToString() { return"ID:"+m_ID; } }
而 GetProduct 方法则根据传入的 ID 从数据库读取数据并返回,它的签名以下:
//Code#03 publicstaticProductGetProduct(stringid);
要想知道编号为 1412 的对象是否从 products 中移除,只需在 Code #01 的最后加上这样一行:
//Code#04 Console.WriteLine(products.Count); 二、一不当心掉进陷阱 不知道你有没有查看 SDK 的习惯,其实 SDK 里面蕴藏着不少对咱们解决问题有启发做用的信息的。如今让咱们看看 SDK 里面可否找到什么蛛丝马迹。 因为 products 的真身是 ListT,因此咱们有必要看看 ListT 是如何实现 IList.Remove 的: This method determines equality using the default equality comparer EqualityComparer.Default for T, the type of values in the list. 原来,ListT 在 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 来看,咱们能够发现 ListT 中的 IList.Remove 判断两个 Product 对象是否相等的方法是从 Object 根类继承下来的 Equals 和 GetHashCode 方法,即比较两个对象的引用是否指向同一个对象。 因为 GetProduct 方法每次返回的都是一个新的对象(暂时让咱们忘记对象缓存这家伙),因而就致使了集合里面出现“不死”对象。 三、不要被同一颗×××打中两次 “不要被同一颗×××打中两次”原意是指同一个错误不要两次犯,这句话暗含着对两个表示错误的对象进行逻辑上的判等,就像上面须要判断两个 Product 的对象在逻辑上是否相等那样。 至此,咱们也知道了令 Remove 从新生效的两个可选办法是: 让 Product 类实现 IEquatableT 接口; 为 Product 类重写 Equals 和 GetHashCode 方法。 在大多数状况下,咱们但愿比较的并非对象的引用,而是对象的内容,与此同时,咱们又不太可能为了这些小对象劳师动众地实现对象缓存,因而,你就颇有可能在相似的代码中邂逅“不死”对象了。
相关文章
相关标签/搜索