Tài liệu Understanding the Property Restrictions pptx

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 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:
class 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;
}