使用屬性 避免將資料成員直接暴露給外界

2021-04-07 13:36:55 字數 1519 閱讀 8609

學習研究.net的早期,經常碰到一些學習c#/.net的朋友問,要屬性這種華而不實的東西做什麼?後來做專案時也時常接到team裡的人的抱怨反饋,為什麼不直接放乙個public欄位?如:

class card

而非要做乙個private欄位+public屬性?

class card

set

}

}我記得在早期的乙個專案裡,team中的乙個朋友甚至厭煩了寫private欄位+public屬性,尤其是碰到一大堆臃腫的data object class的時候,索性自己寫了乙個小工具,來提供乙個類的欄位名和型別,然後自動為該類生成相應的private欄位+public屬性。

我在程式設計的時候是個徹底的實用主義者,用稍微高雅一點的話說叫「不喜歡過度的設計」。如果真的像上面那樣寫card,而且在將來沒有什麼改變的需求,我也不喜歡像上面第2段程式那樣把事情故意搞得複雜。但如果從component的角度來講,總有一些class是要供外部長久地使用,也潛在地在將來有被改變的需求。這時候,提供屬性就很有必要了。

這就是這個item試圖要歸納的使用屬性的理由:

1.可以對賦值做校驗、或者額外的處理

2.可以做執行緒同步

3.可以使用虛屬性、或者抽象屬性

4.可以將屬性置於inte***ce中

5.可以提供get-only或者set-only版本,甚至可以給讀、寫以不同的訪問許可權(c# 2.0支援)

個人感覺3、4條是屬性最大的優點,可以填補沒有「虛字段」或「抽象字段」的缺憾,在設計元件的時候非常有用,也體現了c#這樣的component-oriented語言的精神內涵。

但如果沒有上述理由,而且日後對程式做大的改動可能性比較小時,我想也大可不必非要把每個public欄位都要變成屬性。比如在設計一些輕型的struct,用於互操作的時候,直接使用public欄位沒什麼不好。所以,感覺本條目bill wagner先生使用「always use properties instead of accessible data members」顯得太過強硬。

其實,這裡的討論也表明閱讀《effective c#》一書時需要注意的地方,即effective原則並不是放之四海而皆準的。不同的專案(元件化、復用程度較高的專案?還是「一次編寫、n年都run」的專案),不同的角色(類庫/元件開發人員?還是應用程式開發人員?),有著不同的effective準則。事實上,書中很多items都是從類庫/元件開發人員的角度來考慮的。

關於屬性的效能問題需要談一點,如果僅僅是簡單地以訪問模式來使用屬性,在相當程度上是沒有效能損失的。因為在jit編譯過程中已經做了inline的處理。不過inline處理還是有一些基本的條件,有些情況下jit編譯器不會inline,比如虛呼叫,方法的il**長度過長(目前clr的規定是超過32bytes為**長度過長),有複雜的控制流邏輯,有異常處理等。這些條件都是要麼根本不能使用inline(比如虛屬性),要麼inline的代價太大,容易導致**的bloat,要麼是inline起來很費時間——已經喪失了inline的意義,因為.net的inline機制發生在jit過程中。使用屬性有個別讓人感覺不舒服的地方,比如它影響開發人員的開發效率,但對**執行的效率不產生影響。

請避免直接使用Thread

xiongwanping 2018.04.12 本文件是為了引出baselooper框架做下鋪墊,先提出問題,後面會給出解決辦法。linux 包括linux,android,osx,ios 和windows都提供了執行緒函式,但其粒度太大,比如pthread create,只是把執行緒建立並跑起來,...

盡量避免直接使用 kill 9

kill 9 沒有給程序留下善後的機會 1 關閉socket鏈結 2 清理臨時檔案 3 將自己快要給銷毀的訊息通知給子程序 4 重置自己的終止狀態。通常,應該傳送 15,等一兩秒鐘,如果沒有效果,傳送2,如果還不行,傳送1。總之,在使用 kill 9 前,你應該先使用 kill 15,給目標程序乙個...

訪問屬性與類資料成員

為什麼要使用屬性 乙個良好的類不僅僅要將類的實現部分隱藏起來,還會限制外部對類中成員變數 field 的訪問許可權。在c 中,你可以通過屬性和屬性訪問器 accessor 來達到這個目的,因此屬性也經常被稱為smart field。1 class employee2 類屬性4 public stri...