寫在前面 在書寫C 代碼的時候你是否有過這樣的經歷:經常混用屬性以及公有的數據成員。畢竟他們的用法基本一致,對於使用來說好像沒什麼區別啊。其實我也經常使用類的公有的數據成員來定義一些常量,為了簡單,在一些僅僅需要對外暴露一些常量的類中(如定義一些全局使用的常量),也都是通過定義公有數據成員實現的。直 ...
寫在前面
在書寫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跟大伙進行交流。