使用屬性，避免將數(shù)據(jù)成員直接暴露給外界
學(xué)習(xí)研究.net的早期，經(jīng)常碰到一些學(xué)習(xí)C#/.NET的朋友問，要屬性這種華而不實(shí)的東西做什么？后來做項(xiàng)目時(shí)也時(shí)常接到team里的人的抱怨反饋，為什么不直接放一個(gè)public字段？如：
class Card
{
public string Name;
}
而要做一個(gè)private字段+public屬性
class Card
{
private string name;
public string Name
{
get { return this.name;}
set { this.name=value;}
}
}
我記得在早期的一個(gè)項(xiàng)目里，team中的一個(gè)朋友甚至厭煩了寫private字段+public屬性，尤其是碰到一大堆臃腫的data object class的時(shí)候，索性自己寫了一個(gè)小工具，來提供一個(gè)類的字段名和類型，然后自動(dòng)為該類生成相應(yīng)的private字段+public屬性。
我在編程的時(shí)候是個(gè)徹底的實(shí)用主義者，用稍微高雅一點(diǎn)的話說叫“不喜歡過度的設(shè)計(jì)”。如果真的像上面那樣寫Card，而且在將來沒有什么改變的需求，我也不喜歡像上面第2段程序那樣把事情故意搞得復(fù)雜。但如果從component的角度來講，總有一些class是要供外部長(zhǎng)久地使用，也潛在地在將來有被改變的需求。這時(shí)候，提供屬性就很有必要了。
這就是這個(gè)Item試圖要?dú)w納的使用屬性的理由：
1.可以對(duì)賦值做校驗(yàn)、或者額外的處理
2.可以做線程同步
3.可以使用虛屬性、或者抽象屬性
4.可以將屬性置于interface中
5.可以提供get-only或者set-only版本，甚至可以給讀、寫以不同的訪問權(quán)限（C# 2.0支持）
個(gè)人感覺3、4條是屬性的優(yōu)點(diǎn)，可以填補(bǔ)沒有“虛字段”或“抽象字段”的缺憾，在設(shè)計(jì)組件的時(shí)候非常有用，也體現(xiàn)了C#這樣的component-oriented語言的精神內(nèi)涵。
但如果沒有上述理由，而且日后對(duì)程序做大的改動(dòng)可能性比較小時(shí)，我想也大可不必非要把每個(gè)public字段都要變成屬性。比如在設(shè)計(jì)一些輕型的struct，用于互操作的時(shí)候，直接使用public字段沒什么不好。所以，感覺本條目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”顯得太過強(qiáng)硬。
其實(shí)，這里的討論也表明閱讀《Effective C#》一書時(shí)需要注意的地方，即Effective原則并不是放之四海而皆準(zhǔn)的。不同的項(xiàng)目（組件化、復(fù)用程度較高的項(xiàng)目？還是“一次編寫、N年都run”的項(xiàng)目），不同的角色（類庫/組件開發(fā)人員？還是應(yīng)用程序開發(fā)人員？），有著不同的Effective準(zhǔn)則。事實(shí)上，書中很多Items都是從類庫/組件開發(fā)人員的角度來考慮的。
學(xué)習(xí)研究.net的早期，經(jīng)常碰到一些學(xué)習(xí)C#/.NET的朋友問，要屬性這種華而不實(shí)的東西做什么？后來做項(xiàng)目時(shí)也時(shí)常接到team里的人的抱怨反饋，為什么不直接放一個(gè)public字段？如：
class Card
{
public string Name;
}
而要做一個(gè)private字段+public屬性
class Card
{
private string name;
public string Name
{
get { return this.name;}
set { this.name=value;}
}
}
我記得在早期的一個(gè)項(xiàng)目里，team中的一個(gè)朋友甚至厭煩了寫private字段+public屬性，尤其是碰到一大堆臃腫的data object class的時(shí)候，索性自己寫了一個(gè)小工具，來提供一個(gè)類的字段名和類型，然后自動(dòng)為該類生成相應(yīng)的private字段+public屬性。
我在編程的時(shí)候是個(gè)徹底的實(shí)用主義者，用稍微高雅一點(diǎn)的話說叫“不喜歡過度的設(shè)計(jì)”。如果真的像上面那樣寫Card，而且在將來沒有什么改變的需求，我也不喜歡像上面第2段程序那樣把事情故意搞得復(fù)雜。但如果從component的角度來講，總有一些class是要供外部長(zhǎng)久地使用，也潛在地在將來有被改變的需求。這時(shí)候，提供屬性就很有必要了。
這就是這個(gè)Item試圖要?dú)w納的使用屬性的理由：
1.可以對(duì)賦值做校驗(yàn)、或者額外的處理
2.可以做線程同步
3.可以使用虛屬性、或者抽象屬性
4.可以將屬性置于interface中
5.可以提供get-only或者set-only版本，甚至可以給讀、寫以不同的訪問權(quán)限（C# 2.0支持）
個(gè)人感覺3、4條是屬性的優(yōu)點(diǎn)，可以填補(bǔ)沒有“虛字段”或“抽象字段”的缺憾，在設(shè)計(jì)組件的時(shí)候非常有用，也體現(xiàn)了C#這樣的component-oriented語言的精神內(nèi)涵。
但如果沒有上述理由，而且日后對(duì)程序做大的改動(dòng)可能性比較小時(shí)，我想也大可不必非要把每個(gè)public字段都要變成屬性。比如在設(shè)計(jì)一些輕型的struct，用于互操作的時(shí)候，直接使用public字段沒什么不好。所以，感覺本條目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”顯得太過強(qiáng)硬。
其實(shí)，這里的討論也表明閱讀《Effective C#》一書時(shí)需要注意的地方，即Effective原則并不是放之四海而皆準(zhǔn)的。不同的項(xiàng)目（組件化、復(fù)用程度較高的項(xiàng)目？還是“一次編寫、N年都run”的項(xiàng)目），不同的角色（類庫/組件開發(fā)人員？還是應(yīng)用程序開發(fā)人員？），有著不同的Effective準(zhǔn)則。事實(shí)上，書中很多Items都是從類庫/組件開發(fā)人員的角度來考慮的。