Understanding the Property Restrictions Properties look, act, and feel like fields.. However, they are not true fields, and certain restrictions apply to them: • You can't initialize a
Trang 1Understanding the Property Restrictions
Properties look, act, and feel like fields However, they are not true fields, and certain restrictions apply to them:
• You can't 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 can't 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 can't declare const or readonly properties For example:
const int X { get { } set { } } // compile-time error
NOTE
To make a property read-only, simply omit the set accessor
Using Properties Appropriately
Properties are a powerful feature with a clean, field-like syntax Used in the correct manner properties help to make code easier to understand and maintain However, they are no substitute for careful object-oriented design that focuses on the behavior of objects rather than their properties Accessing private fields through regular methods or through properties does not, by itself, make your code well-designed For example, a bank
account holds a balance You might therefore be tempted to create a Balance property on
a BankAccount class, like this:
Trang 2class BankAccount
{
public money Balance
{
get { }
set { }
}
private money balance;
}
This would be a poor design It fails to represent the functionality required when
withdrawing money from and depositing money into an account (If you know of a bank that allows you to set the balance directly, please let me know.) When you're
programming, 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;
}