薦讀|屬性與可直接訪問的資料成員之間應該如何選

依樂祝發表於2019-07-22

寫在前面

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

作者：依樂祝
原文地址：https://www.cnblogs.com/yilezhu/p/11221447.html

為什麼應該儘量使用屬性

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

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

方便修改

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

public class Customer
{
    private string name;
    public string name
    {
        get=>name;
        set
        {
            if(string.IsNullOrWhiteSpace(value))
            {
                throw new ArgumentException(
                    "Name connot be blank",
                    nameof(Name)
                );
            }
            name=value;
        }
    }
}

假如當初沒有通過公有屬性來實現Name，而是採用了公有資料成員，那麼現在我們就必須在程式碼庫裡找到設定過該成員的每行程式碼，並逐個修改，這會浪費很多時間。

多執行緒支援

由於屬性是通過方法實現的，因此，開發者很容易就能給它新增多執行緒的支援。例如可以像下面這樣實現get與·set訪問器，使外界對Name資料的訪問得以同步：

public class Customer
{
    private object syncHandle = new object();

    private string name;
    public string name
    {
        get
        {
            lock (syncHandle)
            {
                return name;
            }
        }
        set
        {
            if (string.IsNullOrWhiteSpace(value))
            {
                throw new ArgumentException(
                    "Name connot be blank",
                    nameof(Name)
                );
            }

            lock (syncHandle)
            {
                name = value;
            }
        }
    }
}

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

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

public class Customer
{
    public virtual string Name
    {
        get;
        set;
    }
}

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

可以是抽象的，併成為介面的一部分

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

public interface INameValuePair<T>
{
    string Name { get; }
    T Value { get; set; }
}

很方便的控制獲取及設定許可權

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

public class Customer
{
    public virtual string Name
    {
        get;
        protected set;
    }
}

帶引數的屬性

屬性不只適用於簡單的數字欄位。如果某個型別要在其介面中釋出能夠用索引來訪問的內容，那麼就可以建立索引器。這相當於帶有引數的屬性，或者說引數化的屬性。下面這種寫法很有用，用它建立出的屬效能夠返回序列中的某個元素：

public class Customer
{
    public virtual string Name
    {
        get;
        protected set;
    }

    public int this[int index]
    {
        get => theValues[index];
        set => theValues[index] = value;
    }

    private int[] theValues = new int[100];
}
//Accessing an indexer;
int val=someCustomer[i];

此外，若引數是整數的一維索引器，則可以參與資料繫結，若引數不是整數的一維索引器，則可以用來定義對映關係：

private Dictionary<string, Address> addressValues;
    public Address this[string name]
    {
        get => addressValues[name];
        set => addressValues[name] = value;
    }

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

其他說明

後期再把資料成員改成屬性

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

public class Customer
{
    public string Name;
}
string name = customerOne.Name;
customerOne.Name = "yilezhu";

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

屬性的效能損耗

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

總結

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

相關文章