对C#开发的两个基本原则的深入讨论

使用属性避免将数据成员直接公开给外界。

在学习初期。net，经常遇到一些学C#/的朋友。NET又问，你要属性这种华而不实的东西做什么？后来做项目，经常会收到团队里人的抱怨和反馈。为什么不放一个公共字段呢？比如:

类卡
{
公共字符串名称；
}

而是做一个私有字段+公共属性。

类卡
{
私有字符串名称；
公共字符串名称
{
get { return this . Name；}
set { this . name = value；}
}
}

记得在一个早期的项目中，团队中的一个朋友甚至厌倦了写私有字段+公共属性，尤其是遇到大量臃肿的dataobject类时。他只是简单的写了一个小工具，提供一个类的字段名和类型，然后自动为这个类生成对应的私有字段+公共属性。

当我编程的时候，我是一个彻底的实用主义者。用略显优雅的方式，我称之为“我不喜欢过度的设计”。如果真的如上写Card，而且以后也没必要改，我不喜欢故意把上面第2段的程序之类的事情复杂化。但是从组件的角度来看，总有一些类需要长期对外使用，未来也有潜在的需要改变。这时候就需要提供属性了。

这就是为什么这一项试图概括属性的使用:

1.您可以检查分配或进行其他处理。

2.可以做线程同步。

3.可以使用虚拟属性或抽象属性。

4.属性可以放在界面中

5.可以提供get-only或set-only版本，甚至可以给读写不同的访问权限(C# 2.0支持)

个人感觉3和4是属性的优势，可以弥补“虚场”或者“抽象场”的不足。它们在设计组件时非常有用，也体现了C#这样的面向组件语言的精神内涵。

但如果没有这个原因，而且以后对程序做大改动的可能性比较小，我觉得没必要把每个公共字段都做成属性。例如，在为互操作性设计一些轻量级结构时，直接使用公共字段没有任何问题。所以我感觉Bill Wagner先生在这个词条中使用的“总是使用属性而不是可访问的数据成员”太过强烈。

实际上，这里的讨论也说明了，在阅读《有效C#》这本书时，有效原则并不是普遍适用的。不同的项目(组件化和高度复用的项目？或者一个“写一次，运行n年”的项目)，不同的角色(类库/组件开发者？还是应用开发者？)，具有不同的有效标准。其实书中很多条目都是从类库/组件开发者的角度考虑的。