Item 1: Use Properties Instead of Accessible Data Members

 

 

• Because properties are implemented with methods, adding multithreaded support is easier. You can enhance the implementation of the get and set accessors to provide synchronized access to the data:

public class Customer { private object syncHandle = new object(); private string name; public string Name { get { lock (syncHandle) return name; } set { if (string.IsNullOrEmpty(value)) throw new ArgumentException( "Name cannot be blank", "Name"); lock (syncHandle) name = value; } } // More Elided. }

• Properties have all the language features of methods. Properties can be virtual:

public class Customer { public virtual string Name { get; set; } }

• You can extend properties to be abstract and define properties as part of an interface definition

public interface INameValuePair<T> { string Name { get; } T Value { get; set; } }

• The property syntax extends beyond simple data fields. If your type should contain indexed items as part of its interface, you can use indexers (which are parameterized properties).

public int this[int index] { get { return theValues[index]; } set { theValues[index] = value; } } // Accessing an indexer: int val = someObject[i];

Indexers can be virtual or abstract, can be declared in interfaces, and can be read-only or read-write.

Indexers can use noninteger parameters to define maps and dictionaries

public Address this[string name] { get { return adressValues[name]; } set { adressValues[name] = value; } }

In keeping with the multidimensional arrays in C#, you can create multidimensional indexers, with similar or different types on each axis:

public int this[int x, int y] { get { return ComputeValue(x, y); } } public int this[int x, string name] { get { return ComputeValue(x, name); } }

Notice that all indexers are declared with the this keyword. You cannot name an indexer in C#. Therefore, every different indexer in a type must have distinct parameter lists to avoid ambiguity.

• Property accessors should live up to users' expectations

Get accessors should not have observable side effects. Set accessors do modify the state, and users should be able to see those changes. It should not have performance characteristics that are significantly different than a simple data access. Property accessors should not perform lengthy computations, or make cross-application calls (such as perform database queries), or do other lengthy operations that would be  inconsistent with your users’expectations for a property accessor.