Understanding the Property Restrictions

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