建站
咨詢
售后
建站咨詢
新聞中心
本文向大家介紹C# private字段和C# public屬性，可能好多人還不知道C#語言，沒有關(guān)系，看完本文你肯定有不少收獲，希望本文能教會你更多東西。
學(xué)習(xí)研究.NET的早期，經(jīng)常碰到一些學(xué)習(xí)C#.NET的朋友問，要屬性這種華而不實的東西做什么？后來做項目時也時常接到team里的人的抱怨反饋，為什么不直接放一個public字段？如：
- class Card
- {
- public string Name;
- }
- 而要做一個private字段+public屬性
- class Card
- {
- private string name;
- public string Name
- {
- get { return this.name;}
- set { this.name=value;}
- }
- }
我記得在早期的一個項目里，team中的一個朋友甚至厭煩了寫C# private字段和C# public屬性，尤其是碰到一大堆臃腫的data object class的時候，索性自己寫了一個小工具，來提供一個類的字段名和類型，然后自動為該類生成相應(yīng)的C# private字段和C# public屬性。
我在編程的時候是個徹底的實用主義者，用稍微高雅一點的話說叫“不喜歡過度的設(shè)計”。如果真的像上面那樣寫Card，而且在將來沒有什么改變的需求，我也不喜歡像上面第2段程序那樣把事情故意搞得復(fù)雜。但如果從component的角度來講，總有一些class是要供外部長久地使用，也潛在地在將來有被改變的需求。這時候，提供屬性就很有必要了。
這就是這個Item試圖要歸納的使用屬性的理由：
1.可以對賦值做校驗、或者額外的處理
2.可以做線程同步
3.可以使用虛屬性、或者抽象屬性
4.可以將屬性置于interface中
5.可以提供get-only或者set-only版本，甚至可以給讀、寫以不同的訪問權(quán)限（C# 2.0支持）
個人感覺3、4條是屬性最大的優(yōu)點，可以填補沒有“虛字段”或“抽象字段”的缺憾，在設(shè)計組件的時候非常有用，也體現(xiàn)了C#這樣的component-oriented語言的精神內(nèi)涵。
但如果沒有上述理由，而且日后對程序做大的改動可能性比較小時，我想也大可不必非要把每個 public字段都要變成屬性。比如在設(shè)計一些輕型的struct，用于互操作的時候，直接使用public字段沒什么不好。所以，感覺本條目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”顯得太過強硬。
其實，這里的討論也表明閱讀《Effective C#》一書時需要注意的地方，即Effective原則并不是放之四海而皆準(zhǔn)的。不同的項目（組件化、復(fù)用程度較高的項目？還是“一次編寫、N年都 run”的項目），不同的角色（類庫/組件開發(fā)人員？還是應(yīng)用程序開發(fā)人員？），有著不同的Effective準(zhǔn)則。事實上，書中很多Items都是從類庫/組件開發(fā)人員的角度來考慮的。
關(guān)于屬性的性能問題需要談一點，如果僅僅是簡單地以存取模式來使用屬性，在相當(dāng)程度上是沒有性能損失的。因為在JIT編譯過程中已經(jīng)做了inline的處理。不過inline處理還是有一些基本的條件，有些情況下JIT編譯器不會inline，比如虛調(diào)用，方法的IL代碼長度過長（目前CLR的規(guī)定是超過32bytes為代碼長度過長），有復(fù)雜的控制流邏輯，有異常處理等。這些條件都是要么根本不能使用inline（比如虛屬性），要么inline的代價太大，容易導(dǎo)致代碼的bloat，要么是inline起來很費時間——已經(jīng)喪失了 inline的意義，因為.NET的inline機制發(fā)生在JIT過程中。使用屬性有個別讓人感覺不舒服的地方，比如它影響開發(fā)人員的開發(fā)效率，但對代碼運行的效率不產(chǎn)生影響。
【編輯推薦】
- C#窗體里調(diào)用淺談
- C#調(diào)用ListEmployee命令
- C# CreateEmployeeDefinition()函數(shù)
- C#實現(xiàn)斷點續(xù)傳詳細(xì)剖析
- C# Employee對象淺談
本文名稱：C#private字段和public屬性
URL標(biāo)題：http://www.dlmjj.cn/article/cocsejj.html
