Effective C#
文章平均质量分 77
cswch
这个作者很懒,什么都没留下…
展开
-
条款1:使用属性代替可访问的数据成员
在C#中,属性是这样一种元素:他在被访问的时候看起来好像是数据成员,但他却是用方法实现的。.net中的数据绑定类只支持属性,而不支持公有数据成员。 将数据成员直接暴露给外界不符合面向对象的设计原则。 随着时间的推移,新的需求或行为往往会影响原来类型的实现,使用属性比较容易应对这些变化。例如,我们很快发现Customer类不能有一原创 2007-05-10 14:02:00 · 474 阅读 · 0 评论 -
条款2:运行时常量(readonly)优于编译时常量(const)
比较速度:编译时>运行时 灵活性:编译时 编译时常量仅限于数值和字符串,声明的同时必须初始化。 编译后的结果代码中编译时常量被替换位该常量的值。 不能使用new关键字来初始化编译时常量,即使被初始化的常量类型是值类型。 编译时常量默认被定义为静态常量 运行时常量适用于各种类型,只能在构造器或者初始化器中赋值。 在运行时确定它的值,以后对他原创 2007-05-11 17:14:00 · 428 阅读 · 0 评论 -
条款3:操作符is或as优于强制转换
对于类型转换通常有两种选择:使用as操作符;强制转换。另外还有一种比较保险的做法:先用is来做一个转换测试,然后在使用as或强制转换。 as和is操作符都不执行任何用户自定义的转换,而且只能用于引用类型。对于值类型只能使用强制转换。 编译器在产生代码是依据变量编译时的类型,对其运行时的类型一无所知,当进行类型转换时,编译器查看其相容性、有没有用户自定义转换 ,若都原创 2007-05-14 16:10:00 · 389 阅读 · 0 评论 -
条款4:使用Conditional特性代替#if条件编译
使用通常的条件编译,经常把属于程序主逻辑的代码和条件编译代码混在一起。容易引起意想不到的问题。使用Conditional特性把条件编译应用在法方法这一层上,要求我们将条件代码以方法为单位来表达,这样可以把一些函数隔离出来,调试结束后该函数就不会被编译,思路很清晰,削除了莫名其妙的bug。当使用多个Conditional特性时,他们之间的关系是 OR 例如:[Conditional("DEBUG原创 2007-05-28 16:55:00 · 437 阅读 · 0 评论 -
条款5:总是提供ToString()方法
C#默认的ToString()方法会返回类型的名称一般情况下,我们重写ToString()方法即可,当我们期望为类型提供更复杂的输出格式时,要实现IFomattable接口,他为类型用户定制的字符串输出提供了一种标准的方式。当实现了 IFomattable接口时,默认调用的是IFomattable.ToString()而不是Object.ToString()。为了以后获取类的信息比较方便,原创 2007-05-28 17:02:00 · 441 阅读 · 0 评论