使用屬性，避免將資料成員直接暴露給外界
學習研究.net的早期，經常碰到一些學習c#/.net的朋友問，要屬性這種華而不實的東西做什麼？後來做專案時也時常接到team裡的人的抱怨反饋，為什麼不直接放乙個public欄位？如：
class card
public string name;
而要做乙個private欄位+public屬性
class card
private string name;
public string name
get
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過程中。使用屬性有個別讓人感覺不舒服的地方，比如它影響開發人員的開發效率，但對**執行的效率不產生影響。
MSF 的8個基本原則
1.推動資訊共享與溝通 foster open communications 所有的資訊都保留，並公開。2.為共同的遠景而工作 work toward a shared vision 這個目標必須是明確的，沒有二義性 這個目標不是當前就能達到，必須是通過努力才能達到的 這個目標不是空泛的，它應該對專...
物件導向的五個基本原則
本節主要內容 物件導向的五個基本原則 一 單一職責原則 single responsibility principle 就乙個類而言，應該僅有乙個引起它變化的原因。例如 寫乙個 winform 應用程式，需要將資料庫的操作 檔案的操作 演算法的運用等，不需要將這些都寫在 form 這樣的類中。應該將...
關於C 物件導向的五個基本原則
五個基本原則 單一職責原則 single resposibility principle 乙個類，最好只做一件事，只有乙個引起它的變化。單一職責原則可以看做是低耦合 高內聚在物件導向原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。開放封閉原則 open closed pr...