總結(jié)C#開發(fā)技巧
下面的技巧再稀松平常不過，但對于新手可能還有一些難度，容易忽略和忘記。
C#開發(fā)技巧（一）：關(guān)于變量的命名和屬性
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優(yōu)于static readonly。但是在一個比較在的項目中， 在dll局部升級時，如果改變了某個const變量的值，而未升級的dll如果也有這個const變量的話，顯而易見這時候問題將是產(chǎn)生。如 果因此而升級全部dll，反而不值。所以在大型、多變應(yīng)用中，建議使用static readonly代替const。其微乎其微的效率的減損對比 升級布置可能出現(xiàn)的問題還是可以接受的。
除了以上兩種靜態(tài)只讀和常量變量之外，其它變量命名均以下劃線開始，訪問修改符為private(不建議命名為 internal、protected，更不建議命名為public)：
- private static int _maxHeight;
- private int _minHeight;
如果其命名不前置下劃線，易與參數(shù)變量混淆。
對于下面這種定義：
- private int _minHeight = default(int);
- public int MinHeight
- {
- set{
- _minHeight = value;
- }
- get{
- return _minHeight;
- }
- }
初學(xué)者可能覺得有點畫蛇添足，不如直接命名為：
public int MinHeight; 這樣豈不簡單，干嗎還要用getter和setter封裝起來，額外的函數(shù)調(diào)用也使效率有損。
有時候在開發(fā)項目時，開始時我們要畫的可能只是一條蛇，但是項目后期需求變了，改畫一條龍了。所以在項 目初期畫蛇的時候添上一對足還是很有遠見的。
getter與setter(屬性存取器)可以像方法一樣封裝邏輯并且像變量一樣使用，建議所有非靜態(tài)只讀和常量，定 義為private，然后給其添加相應(yīng)屬性存取器，用于賦值與讀取。在其它方法體內(nèi)（包涵類外與類內(nèi)），不建議直接讀寫變量。即使 它目前可以被直接讀寫，我們也要通過調(diào)用屬性存取器也調(diào)用。這一點有點麻煩，但很重要，很高老手有時也會犯錯誤。如下所示：
- 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直接讀寫
- //
- }
即使變量的訪問是受保護的或者或者是私有的，也要使用屬性存取器。
原則是：對于變量的讀取，要用屬性存取器封裝，無論其訪問修飾符如何，即使其屬性存取器內(nèi)除了存取目前 沒有任何其它邏輯。
C#開發(fā)技巧（二）：關(guān)于命名空間和目錄劃分
從命名空間的命名，目錄的劃 分與命名可以看出一個程序員是否有經(jīng)驗，是否很有經(jīng)驗。一個編程老手絕不允許架構(gòu)混亂。
.Net開發(fā)中，一般目錄名與命名空間名稱是對應(yīng)的。關(guān)于命名空間如何劃分，目錄如何分類，這個問題看似簡 單，實際上卻比較復(fù)雜，雖然它不像動植物學(xué)有一套完整的分類學(xué)。
在.Net B/S架構(gòu)中，一般分為如下三個主要的命名空間:
[公司名/作者名].[項目 名].Business
[公司名/作者名].[項目名].Data
[公司名/作者名].[項目名].Web
這三部分可以在一個project中，也可以分置三處。
目錄分類與空間命名之難在于：分類因素是二維的，而分類卻只是一維的。解釋一下：分類是一維的，指一個 詞語只能代表一個分類名稱的含義，無論同時表達兩個含義；分類因素是二維的，指分類可以橫向類別分類，也可以按縱向?qū)傩苑诸?。
假設(shè)我正在開發(fā)一個電子商務(wù)圖書網(wǎng)站[湛藍書店www.ZLBook.cn]，這 個商務(wù)按照常規(guī)，它有用戶中心，幫助中心，支付中心，商品中心等。我的這個項目分為三個project，如下：
Sban.ZLBook.Business
Sban.ZLBook.Data
Sban.ZLBook.Web
在Sban.ZLBook.Web工程中，我下設(shè)UserCenter、HelpCenter、PayCenter、ProductCenter等目錄，這樣的分類 便是按類別橫向分類。
而在這些分類中，肯定都用到了圖片，還有一些css樣式文件，這些文件我放在哪里？我把它們放在Web工程的 Images目錄下(如果不另辟圖片服務(wù)器的話)。如果文件太多，不好管理，其子目錄又可以分為UserCenter、HelpCenter、 PayCenter 、ProductCenter等。如此，Images的目錄的劃分便是按縱向?qū)傩苑诸悺?/P>
關(guān)于具體如何命名，沒有什么通用的方法，要看具體項目。做的項目多了，架構(gòu)才能見水平。命名空間與目錄 建議大寫。
不知道應(yīng)該如何架構(gòu)的時候，不妨翻一翻官方的類庫。
btw:flex工程中，包名(pakeage)與目錄小寫，而類名大寫。
C#開發(fā)技巧（三）：關(guān)于泛型集合，能用則用
用Array,ArrayList,Dictionary等存儲對象集合，面臨的不只是拆裝箱性能損耗的問題。從系統(tǒng)架構(gòu)角度講， 所有對象對象都應(yīng)該是強類型的。為了解決這個問題，從.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 ();
- }
- }
- }
這一條小技巧的建議便是：使用泛型集合避免顯式類型轉(zhuǎn)換。如果您的代碼中有顯式轉(zhuǎn)換，或者有as操作，可 能需要重新考慮一下架構(gòu)。as操作符用起來看似優(yōu)雅，但若用于類型轉(zhuǎn)換不用也罷。
C#開發(fā)技巧（四）：用接口代替類用于參數(shù)
接口是誠實的，能做什么不能做什么一目了然，從來沒有什么欺瞞。不像類，可能擁有其接口沒有定義的方法 或?qū)傩裕幊虝r則有效要避免用到這些方法和屬性。在定義方法時，對于我們需要的對象參數(shù)，我們需要的只是它這個對象的功能 或作用的說明，而接口洽洽就可以提供這些了。使用接口代替類用于參數(shù)，凡是實現(xiàn)這個接口的類都可以用作參數(shù)實例，顯而易見接 口擁有更大的靈活性。
對于方法的返回值，如果要求返回的對象具有某個功能，而這個功能是在接口中聲明的，則只需返回接口即可 。
原則是：參數(shù)的傳入與傳出要盡可能提高其抽象性、擴大其涵蓋范圍。
【編輯推薦】
