建议12: 重写Equals时也要重写GetHashCode

除非考虑到自定义类型会被用作基于散列的集合的键值;否则,不建议重写Equals方法,因为这会带来一系列的问题。

如果编译上一个建议中的Person这个类型,编译器会提示这样一个信息:

“重写 Object.Equals(object o)但不重写 Object.GetHashCode()”

如果重写Equals方法的时候不重写GetHashCode方法,在使用如FCL中的Dictionary类时,可能隐含一些潜在的Bug。还是针对上一个建议中的Person进行编码,代码如下所示:

  1. static Dictionary<Person, PersonMoreInfo> PersonValues = new Dictionary<Person, PersonMoreInfo>();
  2. static void Main(string[] args)
  3. {
  4. AddAPerson();
  5. Person mike = new Person("NB123");
  6. //Console.WriteLine(mike.GetHashCode());
  7. Console.WriteLine(PersonValues.ContainsKey(mike));
  8. }
  9.  
  10. static void AddAPerson()
  11. {
  12. Person mike = new Person("NB123");
  13. PersonMoreInfo mikeValue = new PersonMoreInfo() { SomeInfo = "Mike's info" };
  14. PersonValues.Add(mike, mikeValue);
  15. //Console.WriteLine(mike.GetHashCode());
  16. Console.WriteLine(PersonValues.ContainsKey(mike));
  17. }

本段代码的输出将会是:

True

False

理论上来说,在上一个建议中我们已经重写了Person的Equals方法;也就是说,在AddAPerson方法中的mike和Main方法中的 mike属于“值相等”。于是,将该“值”作为key放入Dictionary中,再在某处根据mike将mikeValue取出来,这会是理所当然的事 情。可是,从上面的代码段中我们发现,针对同一个示例,这种结论是正确的,若是针对不同的mike示例,这种结果就有问题了。

基于键值的集合(如上面的Dictionary)会根据Key值来查找Value值。CLR内部会优化这种查找,实际上,最终是根据Key值的 HashCode来查找Value值。代码运行的时候,CLR首先会调用Person类型的GetHashCode,由于发现Person没有实现 GetHashCode,所以CLR最终会调用Object的GetHashCode方法。将上面代码中的两行注释代码去掉,运行程序得到输出,我们会发 现,Main方法和AddAPerson方法中的两个mike的HashCode是不同的。这里需要解释为什么两者实际对应调用的 Object.GetHashCode会不相同。

Object为所有的CLR类型都提供了GetHashCode的默认实现。每new一个对象,CLR都会为该对象生成一个固定的整型值,该整型值 在对象的生存周期内不会改变,而该对象默认的GetHashCode实现就是对该整型值求HashCode。所以,在上面代码中,两个mike对象虽然属 性值都一致,但是它们默认实现的HashCode不一致,这就导致Dictionary中出现异常的行为。若要修正该问题,就必须重写 GetHashCode方法。Person类的一个简单的重写可以是如下的形式:

  1. public override int GetHashCode()
  2. {
  3. return this.IDCode.GetHashCode();
  4. }

此时再运行本条建议开始时代码的输出,就会发现两者的HashCode是一致的,而Dictionary也会找到相应的键值,输出:True。

细心的读者可能已经发现一个问题,Person类的IDCode属性是一个只读属性。从语法特性本身来讲,可以将IDCode设置为可写;然而从现 实的角度考虑,一个“人”一旦踏入社会,其IDCode就不应该改变,如果要改变,就相当于是另外一个人了。所以,我们应该只实现该IDCode的只读属 性。同理,GetHashCode方法也应该基于那些只读的属性或特性生成HashCode。

GetHashCode方法还存在另外一个问题,它永远只返回一个整型类型,而整型类型的容量显然无法满足字符串的容量,以下的例子就能产生两个同样的HashCode。

  1. string str1 = "NB0903100006";
  2. string str2 = "NB0904140001";
  3. Console.WriteLine(str1.GetHashCode());
  4. Console.WriteLine(str2.GetHashCode());

为了减少两个不同类型之间根据字符串产生相同的HashCode的几率,一个稍作改进版本的GetHashCode方法如下:

  1. public override int GetHashCode()
  2. {
  3. return (System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName + "#" + this.IDCode).GetHashCode();
  4. }

注意 重写Equals方法的同时,也应该实现一个类型安全的接口IEquatable,所以Person类型的最终版本应该如下所示:

  1. class Person : IEquatable<Person>
  2. {
  3. public string IDCode { get; private set; }
  4.  
  5. public Person(string idCode)
  6. {
  7. this.IDCode = idCode;
  8. }
  9.  
  10. public override bool Equals(object obj)
  11. {
  12. return IDCode == (obj as Person).IDCode;
  13. }
  14.  
  15. public override int GetHashCode()
  16. {
  17. return (System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName + "#" + this.IDCode).GetHashCode();
  18. }
  19.  
  20. public bool Equals(Person other)
  21. {
  22. return IDCode == other.IDCode;
  23. }
  24. }

转自:《编写高质量代码改善C#程序的157个建议》陆敏技

编写高质量代码改善C#程序的157个建议——建议12: 重写Equals时也要重写GetHashCode的更多相关文章

  1. 编写高质量代码改善C#程序的157个建议[1-3]

    原文:编写高质量代码改善C#程序的157个建议[1-3] 前言 本文主要来学习记录前三个建议. 建议1.正确操作字符串 建议2.使用默认转型方法 建议3.区别对待强制转换与as和is 其中有很多需要理 ...

  2. 读书--编写高质量代码 改善C#程序的157个建议

    最近读了陆敏技写的一本书<<编写高质量代码  改善C#程序的157个建议>>书写的很好.我还看了他的博客http://www.cnblogs.com/luminji . 前面部 ...

  3. 编写高质量代码改善C#程序的157个建议——建议157:从写第一个界面开始,就进行自动化测试

    建议157:从写第一个界面开始,就进行自动化测试 如果说单元测试是白盒测试,那么自动化测试就是黑盒测试.黑盒测试要求捕捉界面上的控件句柄,并对其进行编码,以达到模拟人工操作的目的.具体的自动化测试请学 ...

  4. 编写高质量代码改善C#程序的157个建议——建议156:利用特性为应用程序提供多个版本

    建议156:利用特性为应用程序提供多个版本 基于如下理由,需要为应用程序提供多个版本: 应用程序有体验版和完整功能版. 应用程序在迭代过程中需要屏蔽一些不成熟的功能. 假设我们的应用程序共有两类功能: ...

  5. 编写高质量代码改善C#程序的157个建议——建议155:随生产代码一起提交单元测试代码

    建议155:随生产代码一起提交单元测试代码 首先提出一个问题:我们害怕修改代码吗?是否曾经无数次面对乱糟糟的代码,下决心进行重构,然后在一个月后的某个周一,却收到来自测试版的报告:新的版本,没有之前的 ...

  6. 编写高质量代码改善C#程序的157个建议——建议154:不要过度设计,在敏捷中体会重构的乐趣

    建议154:不要过度设计,在敏捷中体会重构的乐趣 有时候,我们不得不随时更改软件的设计: 如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个 ...

  7. 编写高质量代码改善C#程序的157个建议——建议153:若抛出异常,则必须要注释

    建议153:若抛出异常,则必须要注释 有一种必须加注释的场景,即使异常.如果API抛出异常,则必须给出注释.调用者必须通过注释才能知道如何处理那些专有的异常.通常,即便良好的命名也不可能告诉我们方法会 ...

  8. 编写高质量代码改善C#程序的157个建议——建议152:最少,甚至是不要注释

    建议152:最少,甚至是不要注释 以往,我们在代码中不写上几行注释,就会被认为是钟不负责任的态度.现在,这种观点正在改变.试想,如果我们所有的命名全部采用有意义的单词或词组,注释还有多少存在的价值. ...

  9. 编写高质量代码改善C#程序的157个建议——建议151:使用事件访问器替换公开的事件成员变量

    建议151:使用事件访问器替换公开的事件成员变量 事件访问器包含两部分内容:添加访问器和删除访问器.如果涉及公开的事件字段,应该始终使用事件访问器.代码如下所示: class SampleClass ...

  10. 编写高质量代码改善C#程序的157个建议——建议150:使用匿名方法、Lambda表达式代替方法

    建议150:使用匿名方法.Lambda表达式代替方法 方法体如果过小(如小于3行),专门为此定义一个方法就会显得过于繁琐.比如: static void SampeMethod() { List< ...

随机推荐

  1. 关于IO流的抽象类

    被一个问题问愣了:java的IO里有哪些抽象类?这个一时半会儿还真记不得,只知道IO有好几类,具体有哪些抽象类从来没有去认真记过.回头仔细看了下分类和继承才发现其实就两对:字节流的抽象类是InputS ...

  2. week-02 线性表

    一.PTA实验作业 题目1:顺序表 7-1 最长连续递增子序列 1. 设计思路 定义结构体List,定义数组Data[maxsize]表示顺序表元素,变量Position表示位置,变量Length表示 ...

  3. 浅谈FPGA的选型

    工欲善其事必先利其器,开发FPGA的第一步,当然是选择一片符合设计需求的芯片. 器件特色 选片第一个关注的应该是FPGA器件的专用资源. 例如是否需要高速接口,如果需要的话,需要多少个通道,各个通道需 ...

  4. linux下用户和组相关的文件及相关管理命令

    1.用户信息文件  /etc/passwd 示例root:x:0:0:root:/root:/bin/bashbin:x:1:1:bin:/bin:/sbin/nologindaemon:x:2:2: ...

  5. GOF23设计模式之建造者模式(builder)

    一.建造者模式概述 建造者模式的本质: 1.分离了对象子组件的单独构造(由Builder负责)和装配(由Director负责).从而可以构造出复杂的对象.这个模式适用于:某个对象的过程复杂的情况下使用 ...

  6. C#简单操作app.config文件

    即将操作的app.config文件内容如下 <?xml version="1.0" encoding="utf-8"?> <configura ...

  7. BigDecimal进行精确运算demo工具类

    package com.js.ai.modules.pointwall.interfac; import java.math.BigDecimal; public class TestDigDecim ...

  8. Linux性能监测:监测目的与工具介绍

    性能监测是系统优化过程中重要的一环,如果没有监测.不清楚性能瓶颈在哪里,优化什么呢.怎么优化呢?所以找到性能瓶颈是性能监测的目的,也是系统优化的关键.本文对Linux性能监测的应用类型.底线和监测工具 ...

  9. java rest jax-rs 漫谈

    rest是什么 REST是英文RepresentationalState Transfer 的缩写,有中文翻译为“具象状态传输”.REST 这个术语是由 RoyFielding 在他的博士论文< ...

  10. mysql 添加字段、删除字段、调整字段顺序

    用过MySQL的朋友,可能都在使用phpMyAdmin,我从2003年开始使用,感觉那东西适合远程mysql管理,并 不适合单机.单数据库的管理操作,特别是开发使用. 给家推荐一个软件管理mysql数 ...