Sunday, March 2, 2008 Control: Properties

Properties encapsulate the state of a component and are the essence of rapid application development (RAD). They allow users to customize components in a design-time environment. The property construct has been supported in Visual Basic for several editions but is not offered by object-oriented programming languages such as C++ and Java. (Properties in JavaBeans are supported indirectly by adherence to a naming convention for accessor methods.) The .NET Framework brings the ease of RAD programming to the object-oriented world by supporting properties as a first-class object-oriented programming construct.

We'll look at the property construct first. Then we'll look at naming guidelines for properties and the advantages of exposing properties.

The Property Construct
Properties are like smart fields that are accessed using fieldlike syntax but implemented using accessor methods. The following example illustrates a simple property construct that defines a Name public property in the Person class:
public class Person {
// The private field below is not part of the property
// construct but contains data that holds the value of
// the Name property.
private string _name;
public string Name {
get {
return _name;
set {
_name = value;

The boldface elements—get, set, and value—are keywords in the C# property syntax. The compiler transforms the code in the get and set blocks into methods that are called property accessors. The get accessor—also called the getter—retrieves the value of the property, while the set accessor—also called the setter—assigns a value to the property. The value identifier denotes the implicit parameter that is passed into the setter.

C# does not have a keyword named property. However, Visual Basic .NET does use the Property keyword as shown in the following example, which shows the keywords in Visual Basic .NET property syntax in boldface:
Private String _name
Public Property Name() As String
Return _name
End Get
Set (ByVal value As String)
_name = value
End Set
End Property

In contrast with C#, value in Visual Basic .NET is not a keyword in property syntax.

Although the get and set accessors are equivalent to methods, they cannot be invoked as methods in C# and Visual Basic .NET but are indirectly accessed by code that assigns or retrieves a property.

The syntax for setting a property is the same as that for setting a field. When you are setting a property, the assigned value must match the declared type of the property:

Person aPerson = new Person();
aPerson.Name = "John"; //Type of Name is string.

The property construct allows you to abstract the storage and implementation of a property from the clients of your component. In our example, a private field holds the data for the Name property. While the backing data for a property is often a private field, the data could reside elsewhere—for example, on disk or in a database—or it could be generated dynamically, as in a property that returns the system time.

A property can define both the get and set accessors or just a single accessor. A property with only a get accessor is a read-only property, while a property with only a set accessor is a write-only property. Although the CLR allows write-only properties, the design guidelines for the .NET Framework discourage them. If your component needs a write-only property, you should implement a method instead of a property to provide the equivalent functionality.

A property can have any access level allowed by the runtime, including public, private, protected, or internal. In C# and Visual Basic .NET, the access level of a property applies to both accessors; it is not possible to have a different access level for each accessor.

Although the get and set accessors are not directly accessible as methods, they are semantically equivalent to methods. Furthermore, they can perform any program logic, be overridden, and throw exceptions. In the next two sections, we'll show you how to override a property and perform value checking in a property accessor.

1 comment:

  1. Good article, but I want to clarify something; actually you can use different access level for each accessor it will be like this:
    public class Customer
    private string _id;

    public string Id
    get { return _id; }
    internal set { _id = value; }
    It’s very useful because, you might want your API to set values to the Id property and you don’t want the UI layer or any other layer to access it,and if you are using abstract class you can make the set protected so only the child classes will be able to use it.
    A lot of developers find it annoying to write properties to the private fields specially if you don’t have a speical logic to write in the set or the get, that’s why microsoft introduce automatic properties in C# 3.0 it will be like writen like this
    public string Id { get; set; } the CLR will automatic generate the fields for you and make property for it, but unfortunately it doesn’t support read only property u must have the 2 accessor so the only way to avoid this is to set the set to private
    public string Id { get; private set; } and here comes the power of having different access level for each accessor, good blog keep moving forward.