[No000018A]改善C#程序的建议11-20

建议11：区别对待 == 和Equals

CLR中将“相等性”分为两类：

1、值相等性：两个变量包含的数值相等。

2、引用相等性：两个变量引用的是内存中的同一个对象。

但并不是所有的类型的比较都是按照其本身，比如string是一个特殊的引用类型，但是在FCL中，string的比较就被重载为针对“类型的值”的比较，而不是“引用本身”的比较。对于自定义类型来说，如果想要实现这样的值比较而不是引用比较的话，则需要重载Equals方法，比如对于Person类，如果IDCode相同，我们可以认为他们是同一个人。

class Person     {         public string IDCode { get; private set; }         public Person(string idCode)         {             this.IDCode = idCode;         }         public override bool Equals(object obj)         {             return IDCode == (obj as Person).IDCode;         }     }

此时通过Equals去比较的话，则就会通过重载后的方法来进行了。

object a = new Person("ABC");  object b = new Person("ABC");  Console.WriteLine(a == b);      //False  Console.WriteLine(a.Equals(b)); //True

说到这里，作者依然没说白“==”和“Equals”的区别，只是说了一句建议的话：“对于引用类型，我们要定义值相等性，应该仅仅去重载Equals方法，同时让==表示引用相等性”。

同时，为了明确有一种方法来肯定比较的是“引用相等性”，FCL提供了Object.ReferenceEquals方法。

bool equal= object.ReferenceEquals(object a,object b);

外事不决问Google，内事不决靠反编译、MSDN了。为了弄懂==和Equals的区别，我作如下搜集整理：

1、==是运算符，而Equals是方法；

2、对于值类型、string类型，==和Equals都是比较值内容相等，使用ILSpy对Int类型进行反编译观察；int类型中的Equals方法内部逻辑就是“==”；

// int [__DynamicallyInvokable, TargetedPatchingOptOut("Performance critical to inline across NGen image boundaries")] public bool Equals(int obj) {     return this == obj; }

string类型则是判断引用地址是否相同或者值内容是否相同，两者有一个符合条件则视为“相等”，请看string类的反编译代码。

// string [__DynamicallyInvokable, ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail), TargetedPatchingOptOut("Performance critical to inline across NGen image boundaries")] public bool Equals(string value) {     if (this == null)     {         throw new NullReferenceException();     }     return value != null && (object.ReferenceEquals(this, value) || (this.Length == value.Length && string.EqualsHelper(this, value)));  }

3、对于引用类型，==和Equals都是比较栈内存中的地址是否相等，并且自定义类型中可以进行运算符重载== 或者Override Equals 来改写认为两对象相等的条件，比如Person类中，我认为只要IDCard相同即对象相同等，此时可以进行重写或者重载。

看到这里，是不是觉得有点迷茫？==好像跟Equals差不多啊，为了想弄清这个问题，我加了作者陆敏技的QQ，以下是聊天记录：

建议12：重写Equals也要重写GetHashCode

坑爹啊！上一个建议的代码原来编译成功，但编译器会友情提示的，这里作者又引出了另外一个建议，何时了啊！

这是因为如果重写Equals方法而不重写GetHashCode方法，在使用Dictionary类的时候，可能会有一个潜在的Bug。

static Dictionary<Person, string> personValues = new Dictionary<Person, string>();         protected void Page_Load(object sender, EventArgs e)         {             AddPerson();             Person mike = new Person("Mike");             Response.Write(personValues.ContainsKey(mike)); //False         }         void AddPerson()         {             Person mike = new Person("Mike");             personValues.Add(mike, "mike");             Response.Write(personValues.ContainsKey(mike)); //True         } 本段代码输出结果：True False

      这段代码的意思是，执行AddPerson()的时候，将idCode=Mike的Person对象存进Dictionary中，然后在Page_Load方法内，也同样new一个idCode=Mike的Person对象，使用ContainsKey方法搜索是否存在此对象Key，结果是不存在此对象。

      你可以会问，上一个建议中，我们已经重写了Person类的Equals方法了，只要idCode相等，我们就可以认为他们是相等的了，为什么此处会找不到Mike呢？

答：这是由于CLR已经优化了Dictionary这种查找，实际上是根据Key值的HashCode来查找Value值的。CLR首先调用Person类型的GetHashCode方法，发现这货根本就没有重写，于是就向上找Object的GetHashCode方法，Object为所有的CLR类型都提供GetHashCode默认实现，每new一个对象，CLR都会为该对象生成一个固定整形值，在对象生命周期内不会改变，对象默认的GetHashCode实现就是该整型值的HashCode，所以，虽然Mike值相等，但是HashCode是不相等的。

若要修正此问题，就必须重写GetHashCode方法

public override int GetHashCode() {   return this.IDCode.GetHashCode(); }

进一步改进：GetHashCode方法存在一个问题，它返回的是一个整形类型，而整形类型的容量长度远远无法满足字符串的长度，也就是说，值不相同的情况下，HashCode可能存在相同的情况，为了减少产生相同HashCode的情况，做改进版本：

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

小结：这个建议至少让我了解了HashCode，以前重写ToString方法的时候，就经常看到GetHashCode这个东东。

建议13：为类型输出格式化字符串

这个建议我读了两次才明白啊。

1、实现IFormattable接口实现ToString()输出格式化字符串

一般我们为类型提供格式化字符串的输出的做法是重写ToString(),但是这种方法提供的字符串输出是非常单一的，所以我们可以实现IFormattable接口的ToString方法，可以让类型根据用户的输入而格式化输出，因为重写的ToString方法没有参数，而实现 IFormattable接口的的ToString方法有参数，还是看代码最清晰。

public class Person : IFormattable     {         public string FirstName { get; set; }         public string LastName { get; set; }         //重写的ToString方法输出字符串比较单一         public override string ToString()         {             return string.Format("{0},{1}", FirstName, LastName);         }         //实现IFormattable接口的ToString方法因为有参数，所以可以实现复杂的逻辑         public string ToString(string format, IFormatProvider formatProvider)         {             if (format == "ch")                 return string.Format("中文名字：{0},{1}", FirstName, LastName);             else                 return string.Format("EnglishName：{0},{1}", FirstName, LastName);         }     }

这样子调用：

Person p = new Person() { FirstName="wayne", LastName="chan" };  Response.Write(p.ToString());  Response.Write(p.ToString("ch",null));  Response.Write(p.ToString("english", null));

2、格式化器

上面的方法是在预见类型会存在格式化字符串输出的需求的时候，提前为类型实现了接口IFormattable，如果类型本身没有提供格式化字符串输出的功能，这时“格式化器”就派上用场了。

//针对Person的格式化器     class PersonFormatter : IFormatProvider, ICustomFormatter     {         //IFormatProvider成员         public object GetFormat(Type formatType)         {             if (formatType == typeof(ICustomFormatter))                 return this;             else                 return null;         }         //ICustomFormatter成员         public string Format(string format, object arg, IFormatProvider formatProvider)         {             Person person = arg as Person;             if (person == null)                 return string.Empty;             switch (format)             {                 case "Ch":                     return string.Format("{0}{1}", person.LastName, person.FirstName);                 case "Eg":                     return string.Format("{0}{1}", person.FirstName, person.LastName);                 default:                     return string.Format("{0}{1}", person.FirstName, person.LastName);             }         }     }

一个典型的格式化器应该要实现IFormatProvider, ICustomFormatter 接口，如果使用的话，就先初始化一个格式化器，如下：

Person person = new Person() { FirstName = "wayne", LastName = "chan", IDCode = "aaaa" };
 //初始化格式化器

PersonFormatter pFormatter = new PersonFormatter();
 Response.Write(pFormatter.Format("Ch", person, null));

其实看到这里，我觉得这个建议已经是非常细致的.NET知识了，一般人遇到这种情况，直接就会使用上一种方法了，在看书的时候，我也想直接跳过算了，但最后想，还是把他也记录下吧，毕竟这也是对自己的提高啊，即使以后还是会把这个知识点遗忘掉，还是可以在本博客找回来啊。

建议14：正确实现浅拷贝和深拷贝

浅拷贝和深拷贝的区别：

浅拷贝：

修改副本的值类型字段不会影响源对象对应的字段，修改副本的引用类型字段会影响源对象，因为源对象复制给副本对象的时候，是引用类型的引用地址，也就是两者引用的是同一个对象。

深拷贝：

无论值类型还是引用类型的字段，修改副本对象不会影响源对象，即使是引用类型，也是重新创建了一个新的对象引用。

要想自定义类型具有Clone拷贝的能力，就得继承ICloneable接口，然后根据需求，实现Clone方法以便实现浅拷贝或者深拷贝。

浅拷贝示例：

namespace WebApplication {     public class Employee : ICloneable     {         public string IDCode { get; set; }         public int Age { get; set; }         public Department Department { get; set; }         //实现ICloneable接口成员         public object Clone()         {             return this.MemberwiseClone();         }     }     public class Department     {         public string Name { get; set; }         public override string ToString()         {             return this.Name;         }     }     public partial class WebForm1 : System.Web.UI.Page     {         protected void Page_Load(object sender, EventArgs e)         {             //初始化Employee对象employeeA             Employee employeeA = new Employee() { IDCode = "A", Age = 10, Department = new Department() { Name = "DepartmentA" } };             //从employeeA 浅拷贝出 employeeB             Employee employeeB = employeeA.Clone() as Employee;             //修改employeeB对象的属性             employeeA.IDCode = "B";             employeeA.Age = 15;             employeeA.Department.Name = "DepartmentB";             //输出以便验证             Response.Write(employeeB.IDCode); // A              Response.Write(employeeB.Age);    //10             Response.Write(employeeB.Department.ToString()); //DepartmentB         }     } }

从输出结果可以验证得到结果：

1、IDCode即使是string引用类型，Object.MemberwiseClone 依然为其创造了副本，在浅拷贝中，我们可以将string当做值类型来看待。

2、Employee的Department属性是引用类型，改变源对象employeeA中的值，会影响到副本对象employeeB

深拷贝示例

建议使用序列化的形式进行深拷贝：

//实现ICloneable接口成员         public object Clone()         {             //浅拷贝             //return this.MemberwiseClone();               //使用序列化进行深拷贝             using (Stream objectStream = new MemoryStream())             {                 IFormatter formatter = new BinaryFormatter();                 formatter.Serialize(objectStream, this);                 objectStream.Seek(0, SeekOrigin.Begin);                 return formatter.Deserialize(objectStream) as Employee;             }         }

这里我按照书中的代码来运行程序，结果爆黄页错误了，提示信息是：

中的类型“WebApplication.Employee”未标记为可序列化。

因为之前有相关的开发经验，知道那是因为实体类没有被标记为序列化属性，难道作者编写示例的时候没有检查出这个错误？或者是其他原因?

我们在实体类上标记一下即可运行成功，这是修改源对象employeeA中的值也不会影响到副本对象employeeB了。

[Serializable]   public class Employee : ICloneable   [Serializable]   public class Department

建议15：使用dynamic来简化反射实现

dynamic是Framework4.0的新特性，dynamic的出现让C#具有了弱语言类型的特性，编译器在编译的时候，不再对类型进行检查，不会报错，但是运行时如果执行的是不存在的属性或者方法，运行程序还是会抛出RuntimeBinderException异常。

var 与 dynamic 的区别

var是编译器给我们的语法糖，编译期会匹配出实际类型并且替换该变量的声明。

dynamic 被编译后，实际是一个object类型，只不过编译器对dynamic做特殊处理，将类型检查放到了运行期。

这从VS的编译器窗口可以看出来，var 声明的变量在VS中有智能提示，因为VS能推断出来实际类型；dynamic声明的变量没有智能提示。

利用dynamic 简化反射

public class DynamicSample     {         public string Name { get; set; }         public int Add(int a, int b)         {             return a + b;         }     }     public partial class DynamicPage : System.Web.UI.Page     {         protected void Page_Load(object sender, EventArgs e)         {             //普通的反射做法             DynamicSample dynamicSample = new DynamicSample();             var addMethod = typeof(DynamicSample).GetMethod("Add");             int res = (int)addMethod.Invoke(dynamicSample, new object[] { 1, 2 });                           //dynamic的做法，简洁，推荐             dynamic dynamicSample2 = new DynamicSample();             int res2 = dynamicSample2.Add(1, 2); //Add不会智能提示出来         }     }

使用dynamic还有一个优点就是，比没有优化过的反射性能好，跟优化过的反射性能相当，但代码整洁度高，作者也是贴了代码并贴出运行结果而已，没有作过多的介绍，所以此处作罢了。

建议16：元素数量可变的情况下不应使用数组

1、从内存使用角度看，数组在创建时被分配一段固定长度的内存，数据的存储结构一旦被分配，就不能再变化；

2、ArrayList是链表结构，可以动态增减内存空间；

3、List<T>是ArrayList的泛型实现，省去了拆箱和装箱带来的开销。

基于数组本身在内存的特点，因此，在使用数组的时候需要注意大对象（占用内存找过85000字节的对象）的问题，因为他们会被分配在大对象堆里，在回收过程中效率极低，所以，数组的长度不宜过份大。

再来回应本建议主旨，现在我们知道数组是不可变的，如果非得让数组变成“可变”的，那就只有像String那样，重新构造一个新的数组，再Copy过去了，这样可想性能是如此的差啊。

public static class ClassForExtensions     {         public static Array ReSize(this Array array, int newSize)         {             //返回当前数组、指针或引用类型包含的或引用的对象的 System.Type             Type t = array.GetType().GetElementType();             //构造一个满足需要的新数组             Array newArray = Array.CreateInstance(t, newSize);             //将旧数组的内容Copy到新数组             Array.Copy(array, 0, newArray, 0, Math.Min(array.Length, newSize));             return newArray;         }     }

总结：

此建议跟“如果大规模string字符串拼接就用StringBuilder”异曲同工。

建议17：多数情况下使用foreach进行循环遍历

为什么会有这个建议，我就有些不解了，作者先是参照IEnumerator、IEnumerable自己实现了一个类似的迭代器，然后说它的内部实现用了for循环或者是while循环，写法都有点啰嗦，然后就说foreach出现了，还说foreach最大限度简化了代码，然后开始分析IL了，关于这个建议点，我觉得说得挺含糊的，不过根据作者的观点，foreach循环除了提供简化的语法外，还有两个优势。

1、自动将代码置入try-finally块

2、若类型实现IDispose接口，foreach会在循环结束后自动调用Dispose方法。

建议18：foreach不能代替for

foreach不支持循环时对集合进行增删操作，而for循环可以，其原因是foreach循环使用了迭代器进行集合的遍历，在迭代器里维护了一个集合版本的控制，我们对集合进行增删操作的时候，都会产生一个新的版本号，当foreach循环调用MoveNext 方法遍历元素时会对版本号进行检测，一旦检测版本号变动，则抛出异常，以下是我使用ILSpy反编译得出的代码， IEnumerator接口只定义了MoveNext成员，具体实现需要反编译其实现类，我是对List<T>进行反编译的。

// System.Collections.Generic.List<T>.Enumerator [__DynamicallyInvokable] public bool MoveNext() {     List<T> list = this.list;     if (this.version == list._version && this.index < list._size)     {         this.current = list._items[this.index];         this.index++;         return true;     }     return this.MoveNextRare(); }

List<T>中对版本号的检测没有抛出异常，而某些实现类则会，比如：ArrayList类

// System.Collections.ArrayList.ArrayListEnumeratorSimple public bool MoveNext() {     if (this.version != this.list._version)     {         throw new InvalidOperationException(Environment.GetResourceString("InvalidOperation_EnumFailedVersion"));     }    // other code }

而for循环则不会出现这个问题，我们通常在for循环的内部使用索引器来对集合成员的访问，不对版本号进行判断检测。以下是对List<T>的索引器的反编译代码。

// System.Collections.Generic.List<T> [__DynamicallyInvokable] public T this[int index] {     [__DynamicallyInvokable, TargetedPatchingOptOut("Performance critical to inline across NGen image boundaries")]     get     {         if (index >= this._size)         {             ThrowHelper.ThrowArgumentOutOfRangeException();         }         return this._items[index];     }     [__DynamicallyInvokable, TargetedPatchingOptOut("Performance critical to inline across NGen image boundaries")]     set     {         if (index >= this._size)         {             ThrowHelper.ThrowArgumentOutOfRangeException();         }         this._items[index] = value;         this._version++;     } }

可以看出，get属性没有对_version版本号进行检测，只要索引不超过size即可，而set属性，会对_version版本号+1。

建议19：使用更有效的对象和集合初始化

这个建议应该很多人都知道或者都已经在用了，如果你还不知道，那你就out了。

List<Person> list = new List<Person>(); Person p = new Person(); p.ID = 1; p.Name = "Tommy"; list.Add(p);

骚年，你还在这样进行对象、集合初始化吗？奥特了，借助了.NET的高级语法，我们可以使用对象和集合的初始化器来写出更加优雅的代码。设定项在大括号中对属性进行赋值

List<Person> lst = new List<Person>() {     new Person(){ ID=1,Name="Tommy"},    new Person(){ ID=2,Name="Sammy"} };

初始化设定项除了为对象、集合初始化方便外，还为Linq查询时的匿名类型进行属性的初始化的方便。

List<Person> lst = new List<Person>()  {      new Person(){ Age = 10,Name="Tommy"},     new Person(){ Age = 20,Name="Sammy"}  }; var entity = from p in lst              select new { p.Name, AgeScope = p.Age > 10 ? "Old" : "Young" }; foreach (var item in entity) {    Response.Write(string.Format("name is {0},{1}", item.Name, item.AgeScope)); }

AgeScope 属性是经过计算得出的，有了如此方便的初始化方式，使得代码更加优雅灵活。

建议20：使用泛型集合代替非泛型集合