【IT168技术文档】
下面的技巧再稀松平常不过，但对于新手可能还有一些难度，容易忽略和忘记。
一，关于变量的命名和属性
static readonly与const的变量，作用是一样的，无论访问修饰符是不是public，还是其它(private、 protected、internal），变量名称一般为大写，中间以下划线。
public static readonly int MAX_HEIGHT;
public const int MIN_HEIGHT = 10;
有些程序员对大写不敏感，上例中，MAX_HEIGHT用Max_Height代替也未尝不可 ，甚至MaxHeight也可以。在.Net类库中，int.MaxValue与int.MinValue便是这样定义的。
const常量更确切的说是编译时常量，因为它在运行时是不存在的，在编译中所有变量引用将被实际值替掉。而 static readonly则不然，它在运行时也是存在的。从原理上讲，论效率const优于static readonly。但是在一个比较在的项目中， 在dll局部升级时，如果改变了某个const变量的值，而未升级的dll如果也有这个const变量的话，显而易见这时候问题将是产生。如 果因此而升级全部dll，反而不值。所以在大型、多变应用中，建议使用static readonly代替const。其微乎其微的效率的减损对比 升级布置可能出现的问题还是可以接受的。
除了以上两种静态只读和常量变量之外，其它变量命名均以下划线开始，访问修改符为private(不建议命名为 internal、protected，更不建议命名为public)：
private static int _maxHeight;
private int _minHeight; 如果其命名不前置下划线，易与参数变量混淆。
对于下面这种定义：
private int _minHeight = default(int);
public int MinHeight
{
set{
_minHeight = value;
}
get{
return _minHeight;
}
}
初学者可能觉得有点画蛇添足，不如直接命名为：
public int MinHeight; 这样岂不简单，干吗还要用getter和setter封装起来，额外的函数调用也使效率有损。
有时候在开发项目时，开始时我们要画的可能只是一条蛇，但是项目后期需求变了，改画一条龙了。所以在项 目初期画蛇的时候添上一对足还是很有远见的。
getter与setter(属性存取器)可以像方法一样封装逻辑并且像变量一样使用，建议所有非静态只读和常量，定 义为private，然后给其添加相应属性存取器，用于赋值与读取。在其它方法体内（包涵类外与类内），不建议直接读写变量。即使 它目前可以被直接读写，我们也要通过调用属性存取器也调用。这一点有点麻烦，但很重要，很高老手有时也会犯错误。如下所示：
private int _minHeight = int.MinValue;
public int MinHeight//或者是 protected、internal，甚至是private
{
set{
_minHeight = value;
//即使这里目前没有其它处理逻辑
}
get{
return _minHeight;
}
}
public void Method1 (int minHeight)
{
this.MinHeight = minHeight;//在这里不要使用 this._minHeight直接读写
//
}
即使变量的访问是受保护的或者或者是私有的，也要使用属性存取器。
原则是：对于变量的读取，要用属性存取器封装，无论其访问修饰符如何，即使其属性存取器内除了存取目前 没有任何其它逻辑。
二，关于命名空间和目录划分
从命名空间的命名，目录的划 分与命名可以看出一个程序员是否有经验，是否很有经验。一个编程老手绝不允许架构混乱。
.Net开发中，一般目录名与命名空间名称是对应的。关于命名空间如何划分，目录如何分类，这个问题看似简 单，实际上却比较复杂，虽然它不像动植物学有一套完整的分类学。
在.Net B/S架构中，一般分为如下三个主要的命名空间:
[公司名/作者名].[项目 名].Business
[公司名/作者名].[项目名].Data
[公司名/作者名].[项目名].Web 这三部分可以在一个project中，也可以分置三处。
目录分类与空间命名之难在于：分类因素是二维的，而分类却只是一维的。解释一下：分类是一维的，指一个 词语只能代表一个分类名称的含义，无论同时表达两个含义；分类因素是二维的，指分类可以横向类别分类，也可以按纵向属性分类 。
假设我正在开发一个电子商务图书网站[湛蓝书店www.ZLBook.cn]，这 个商务按照常规，它有用户中心，帮助中心，支付中心，商品中心等。我的这个项目分为三个project，如下：
Sban.ZLBook.Business
Sban.ZLBook.Data
Sban.ZLBook.Web
在Sban.ZLBook.Web工程中，我下设UserCenter、HelpCenter、PayCenter、ProductCenter等目录，这样的分类 便是按类别横向分类。
而在这些分类中，肯定都用到了图片，还有一些css样式文件，这些文件我放在哪里？我把它们放在Web工程的 Images目录下(如果不另辟图片服务器的话)。如果文件太多，不好管理，其子目录又可以分为UserCenter、HelpCenter、 PayCenter 、ProductCenter等。如此，Images的目录的划分便是按纵向属性分类。
关于具体如何命名，没有什么通用的方法，要看具体项目。做的项目多了，架构才能见水平。命名空间与目录 建议大写。
不知道应该如何架构的时候，不妨翻一翻官方的类库。
btw:flex工程中，包名(pakeage)与目录小写，而类名大写。
三，关于泛型集合，能用则用
用Array,ArrayList,Dictionary等存储对象集合，面临的不只是拆装箱性能损耗的问题。从系统架构角度讲， 所有对象对象都应该是强类型的。为了解决这个问题，从.Net2开始，便有了泛型。看如下代码：
public class Mobile
{
private ArrayList friends= new ArrayList();//这里用ArrayList便不足取
public void Add (IFriend f)
{
friends.Add(f)
}
private void SayBless()
{
for (int i = 0; i < friends.Count; i++)
{
IFriend f riend=(IFriend )friends[i];//这里拆装时，必须知道其元素的类型是IFriend
friend.Say ();
}
}
} 这一条小技巧的建议便是：使用泛型集合避免显式类型转换。如果您的代码中有显式转换，或者有as操作，可 能需要重新考虑一下架构。as操作符用起来看似优雅，但若用于类型转换不用也罢。
四，用接口代替类用于参数
接口是诚实的，能做什么不能做什么一目了然，从来没有什么欺瞒。不像类，可能拥有其接口没有定义的方法 或属性，而编程时则有效要避免用到这些方法和属性。在定义方法时，对于我们需要的对象参数，我们需要的只是它这个对象的功能 或作用的说明，而接口洽洽就可以提供这些了。使用接口代替类用于参数，凡是实现这个接口的类都可以用作参数实例，显而易见接 口拥有更大的灵活性。
对于方法的返回值，如果要求返回的对象具有某个功能，而这个功能是在接口中声明的，则只需返回接口即可 。
原则是：参数的传入与传出要尽可能提高其抽象性、扩大其涵盖范围。
