Understanding the Property Restrictions

Sở hữu sự hiểu biết hạn chế Properties nhìn, hành động, và cảm thấy như các lĩnh vực. Tuy nhiên, họ không thật sự lĩnh vực, và một số hạn chế áp dụng đối với họ
Nội dung trích xuất từ tài liệu:
Understanding the Property Restrictions Understanding the Property RestrictionsProperties look, act, and feel like fields. However, they are not true fields, and certainrestrictions apply to them: • You cant initialize a property of a struct or class by using a set accessor. The code in the following example is illegal as the location variable has not been initialized (by using new): • ScreenPosition location; location.X = 40; // compile-time error, location not assigned NOTE This may seem trivial, but if X was a field rather than a property, the code would be legal. What this really means is that there are some differences between fields and properties. You should define structs and classes by using properties from the start, rather than by using fields that you later migrate to properties—code that uses your classes and structs might no longer work if you change fields into properties. • You cant use a property as a ref or out argument (whereas you can use a writeable field as a ref or out argument). For example: MyMethod(ref location.X); // compile-time error • A property can contain at most one get accessor and one set accessor. A property cannot contain other methods, fields, or properties. • The get and set accessors cannot take any parameters. The data being assigned is passed to the set accessor automatically, by using the value variable. • You cant declare const or readonly properties. For example: const int X { get { ... } set { ... } } // compile-time errorNOTETo make a property read-only, simply omit the set accessor.Using Properties AppropriatelyProperties are a powerful feature with a clean, field-like syntax. Used in the correctmanner properties help to make code easier to understand and maintain. However, theyare no substitute for careful object-oriented design that focuses on the behavior of objectsrather than their properties. Accessing private fields through regular methods or throughproperties does not, by itself, make your code well-designed. For example, a bankaccount holds a balance. You might therefore be tempted to create a Balance property ona BankAccount class, like this:class BankAccount{ ... public money Balance { get { ... } set { ... } } private money balance;}This would be a poor design. It fails to represent the functionality required whenwithdrawing money from and depositing money into an account. (If you know of a bankthat allows you to set the balance directly, please let me know.) When youreprogramming, try not to lose the expression of the problem in a mass of low-level syntax;try to express the problem you are solving in the solution:class BankAccount{ ... public money Balance { get { ... } } public void Deposit(money amount) { ... } public bool Withdraw(money amount) { ... } private money balance;}