總結C#開發技巧
下面的技巧再稀松平常不過，但對于新手可能還有一些難度，容易忽略和忘記。
C#開發技巧（一）：關于變量的命名和屬性
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直接讀寫
- //
- }
即使變量的訪問是受保護的或者或者是私有的，也要使用屬性存取器。
原則是：對于變量的讀取，要用屬性存取器封裝，無論其訪問修飾符如何，即使其屬性存取器內除了存取目前 沒有任何其它邏輯。
C#開發技巧（二）：關于命名空間和目錄劃分
從命名空間的命名，目錄的劃 分與命名可以看出一個程序員是否有經驗，是否很有經驗。一個編程老手絕不允許架構混亂。
.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)與目錄小寫，而類名大寫。
C#開發技巧（三）：關于泛型集合，能用則用
用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操作符用起來看似優雅，但若用于類型轉換不用也罷。
C#開發技巧（四）：用接口代替類用于參數
接口是誠實的，能做什么不能做什么一目了然，從來沒有什么欺瞞。不像類，可能擁有其接口沒有定義的方法 或屬性，而編程時則有效要避免用到這些方法和屬性。在定義方法時，對于我們需要的對象參數，我們需要的只是它這個對象的功能 或作用的說明，而接口洽洽就可以提供這些了。使用接口代替類用于參數，凡是實現這個接口的類都可以用作參數實例，顯而易見接 口擁有更大的靈活性。
對于方法的返回值，如果要求返回的對象具有某個功能，而這個功能是在接口中聲明的，則只需返回接口即可 。
原則是：參數的傳入與傳出要盡可能提高其抽象性、擴大其涵蓋范圍。
【編輯推薦】
