这些技巧再浅显平常不过,初学者很容易忽略。相信越是越老道的程序员,越重视这些稀疏平常的技巧。
一,关于变量的命名和属性
static readonly与const的变量,作用是一样的,无论访问修饰符是不是public,还是其它(private、 protected、internal),变量名称一般为大写,中间以下划线。
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 int _minHeight;
如果其命名不前置下划线,易与参数变量混淆。
对于下面这种定义:
public int MinHeight
{
set {
_minHeight = value;
}
get {
return _minHeight;
}
}
初学者可能觉得有点画蛇添足,不如直接命名为:
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
这样岂不简单,干吗还要用getter和setter封装起来,额外的函数调用也使效率有损。
有时候在开发项目时,开始时我们要画的可能只是一条蛇,但是项目后期需求变了,改画一条龙了。所以在项 目初期画蛇的时候添上一对足还是很有远见的。
getter与setter(属性存取器)可以像方法一样封装逻辑并且像变量一样使用,建议所有非静态只读和常量,定 义为private,然后给其添加相应属性存取器,用于赋值与读取。在其它方法体内(包涵类外与类内),不建议直接读写变量。即使 它目前可以被直接读写,我们也要通过调用属性存取器也调用。这一点有点麻烦,但很重要,很高老手有时也会犯错误。如下所示:
public int MinHeight//或者是 protected、internal,甚至是private
{
set {
_minHeight = value;
//即使这里目前没有其它处理逻辑
}
get {
return _minHeight;
}
}
public void Method1 ( int minHeight)
{
this .MinHeight = minHeight;//在这里不要使用 this._minHeight直接读写
//
![](https://www.cnblogs.com/Images/dot.gif)
}
即使变量的访问是受保护的或者或者是私有的,也要使用属性存取器。
原则是:对于变量的读取,要用属性存取器封装,无论其访问修饰符如何,即使其属性存取器内除了存取目前 没有任何其它逻辑。
二,关于命名空间和目录划分
从命名空间的命名,目录的划 分与命名可以看出一个程序员是否有经验,是否很有经验。一个编程老手绝不允许架构混乱。
.Net开发中,一般目录名与命名空间名称是对应的。关于命名空间如何划分,目录如何分类,这个问题看似简 单,实际上却比较复杂,虽然它不像动植物学有一套完整的分类学。
在.Net B/S架构中,一般分为如下三个主要的命名空间:
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
这三部分可以在一个project中,也可以分置三处。
目录分类与空间命名之难在于:分类因素是二维的,而分类却只是一维的。解释一下:分类是一维的,指一个 词语只能代表一个分类名称的含义,无论同时表达两个含义;分类因素是二维的,指分类可以横向类别分类,也可以按纵向属性分类 。
假设我正在开发一个电子商务图书网站[湛蓝书店http://www.zlbook.cn/],这 个商务按照常规,它有用户中心,帮助中心,支付中心,商品中心等。我的这个项目分为三个project,如下:
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开始,便有了泛型。看如下代码:
{
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操作符用起来看似优雅,但若用于类型转换不用也罢。
四,用接口代替类用于参数
接口是诚实的,能做什么不能做什么一目了然,从来没有什么欺瞒。不像类,可能拥有其接口没有定义的方法 或属性,而编程时则有效要避免用到这些方法和属性。在定义方法时,对于我们需要的对象参数,我们需要的只是它这个对象的功能 或作用的说明,而接口洽洽就可以提供这些了。使用接口代替类用于参数,凡是实现这个接口的类都可以用作参数实例,显而易见接 口拥有更大的灵活性。
对于方法的返回值,如果要求返回的对象具有某个功能,而这个功能是在接口中声明的,则只需返回接口即可 。
原则是:参数的传入与传出要尽可能提高其抽象性、扩大其涵盖范围。