寫在前面

在書寫C#代碼的時候你是否有過這樣的經歷：經常混用屬性以及公有的數據成員。畢竟他們的用法基本一致，對于使用來說好像沒什么區別啊。其實我也經常使用類的公有的數據成員來定義一些常量，為了簡單，在一些僅僅需要對外暴露一些常量的類中（如定義一些全局使用的常量），也都是通過定義公有數據成員實現的。直到看到世界世界知名專家Bill Wagner的那本《More Effective C#》之后才意識到應該盡量“使用屬性而不是可直接訪問的數據成員”。因為屬性具有修改的便捷性，多線程的支持等等。

為什么應該盡量使用屬性

屬性一直是C#語言的特色，目前的屬性機制比C#剛引人它的時候更為完備，這使得開發者能夠通過屬性實現很多功能，例如，可以給getter與setter ?設定不同的訪問權限。與直接通過數據成員來編程的方式相比，自動屬性可以省去大量的編程工作，而且開發者可以通過該機制輕松地定義出只讀的屬性。此外還可以結合以表達式為主體的 （ expression-bodied） 寫法將代碼變得更緊湊。有了這些機制就不應該繼續在類型中創建公有 （ publish） 字段， 也不應該繼續手工編寫get與set方法。屬性既可以令調用者通過公有接口訪問相關的數據成員 ， 又可以確保這些成員得到面向對象式的封裝。

注：在C#語言中， 屬性這種元素可以像數據成員一樣被訪問， 但它們其實是通過方法來實現的。

方便修改

在所有的類與結構中，應該多使用屬性，這樣可以讓你在發現新的需求時，更為方便的修改代碼。比如說，如果你現在決定Customer類型的name(名字)數據不應該出現空白值，那么只需要修改Name屬性的代碼即可：

假如當初沒有通過公有屬性來實現Name，而是采用了公有數據成員，那么現在我們就必須在代碼庫里找到設置過該成員的每行代碼，并逐個修改，這會浪費很多時間。

多線程支持

由于屬性是通過方法實現的，因此，開發者很容易就能給它添加多線程的支持。例如可以像下面這樣實現get與·set訪問器，使外界對Name數據的訪問得以同步：

方法具備的好處，屬性全有

C# 方法所具備的一些特性同樣可以體現在屬性身上，其中很明顯的一條就是屬性也可以聲明為virtual:

Note：剛才幾個例子涉及屬性的地方用的都是隱式寫法。采用隱式寫法時，開發者不用自己在屬性的getter與setter中編寫過多邏輯。也就是說，我們在用屬性來表示比較簡單的字段時，無需通過大量的模板代碼來構建這個屬性，編譯器會為我們自動創建私有字段（該字段通常稱為后援字段，并實現get，set這兩個訪問器所需的簡單邏輯）。

可以是抽象的，并成為接口的一部分

屬性也可以是抽象的，從而成為接口定義的一部分，這種屬性寫起來與隱士屬性相似。下面這段代碼，就演示了怎樣在泛型接口中定義屬性。雖然與隱士屬性的寫法相似，但這種屬性沒有對應的實現物，定義該屬性的接口只是要求實現本接口的類型都必須滿足接口所訂立的契約，也就是必須正確的提供Name及Value這兩個屬性：

很方便的控制獲取及設置權限

對于類型中的屬性來說，它的訪問器分成getter(獲取器)與setter(設置器)這兩個單獨的方法，這使得我們能夠對二者施加不同的修飾符，以便分別控制外界對該屬性的獲取權限以及設置權限。由于這兩種權限可以分開調整，因此我們能夠通過屬性更為靈活的封裝數據元素：

帶參數的屬性

屬性不只適用于簡單的數字字段。如果某個類型要在其接口中發布能夠用索引來訪問的內容，那么就可以創建索引器。這相當于帶有參數的屬性，或者說參數化的屬性。下面這種寫法很有用，用它創建出的屬性能夠返回序列中的某個元素：

此外，若參數是整數的一維索引器，則可以參與數據綁定，若參數不是整數的一維索引器，則可以用來定義映射關系：

注意：索引器一律要用this關鍵字來聲明。由于C#不允許給索引器起名字，因此同一個類型的索引器必須在參數列表上有所區別，否則就會產生歧義。另外，索引器必須明確的實現出來，而不能像簡單屬性那樣由系統默認生成。

其他說明

后期再把數據成員改成屬性

盡管屬性是個相當好的機制，可是還有人想先創建普通的數據成員，然后在確實有必要的情況下再將其替換成屬性，以便使用屬性所具備的優勢。這種想法聽上去很有道理，但實際并不合適。例如，如下定義一個普通數據成員的代碼：

其實我也經常這樣用，不過都是定義一些靜態的全局常量。雖然在使用上屬性可以像數據成員那樣來訪問，但是從MSIL的角度來看，卻不是這樣，因為訪問屬性時所使用的指令與訪問數據成員所使用的指令是有區別的。因此如果把數據成員改成屬性，則會破壞二進制層面的兼容機制，使得很難單獨更新某一個程序集，需要全部更新。

屬性的性能損耗

你可能要問了，是以屬性的形式訪問數據比較快，還是以數據成員的形式訪問比較快？其實前者的效率雖然不會超過后者，但也未必落后于它。因為JIT編譯器會對某些方法調用進行內聯處理，其中也包括屬性。如果編譯器對屬性進行內聯處理的話，那么它的效率就會與數據成員相同。即便沒有內聯，兩者的差別也可以忽略不計。

總結

今天給大家介紹了使用屬性來訪問數據成員的諸多優勢，因此建議如果要在類型的公有或受保護的接口中發布數據，那么應該以屬性的形式來發布，對于序列或字典來說，應該以索引器的形式發布。在日常的開發中雖然用屬性的形式來封裝變量會占用你一到兩分鐘的時間，但是如果你一開始沒有使用屬性，后來想用屬性來設計，那么可能就得用好幾個小時去修正了。現在多花點時間，將來會省很多功夫。文章大多內容來自觀看《More Effective C#》第一小節的內容所做的筆記，當然后續我還會對剩下的提升C#代碼的50個方法進行總結記錄，敬請期待吧。如果你有興趣可以加DotNetCore實戰項目交流群637326624跟大伙進行交流。

總結

以上是生活随笔為你收集整理的荐读|属性与可直接访问的数据成员之间应该如何选的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。