Sunday, March 1, 2009

C# Property

In C#, properties are nothing but natural extension of data fields. They are usually known as ‘smart fields’ in C# community.

Properties provide a flexible mechanism to read, write, or compute the values of private fields. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.

The significance of these properties is its usability. These properties need not be called with any function names like objectname.get or objectname.set etc., But they can be directly assigned the values or retrieve the values.

// private member variable
private int hour;

// public property
public int Hour
get { return hour; }
set { hour = value; }

Where access modifier can be private, public, protected or internal.

Languages that don't have properties will use methods (functions or procedures) for encapsultation. The idea is to manage the values inside of the object, state, avoiding corruption and misuse by calling code.


-> Properties enable a class to expose a public way of getting and setting values, while hiding implementation or verification code.
-> A get property accessor is used to return the property value, and a set accessor is used to assign a new value. These accessors can have different access levels.
-> The set accessor has a free variable available in it called value, which gets created automatically by the compiler. We can't declare any variable with the name value inside the set accessor.
-> A property should have at least one accessor, either set or get.
-> Since normal data fields and properties are stored in the same memory space, in C#, it is not possible to declare a field and property with the same name.
-> You can add a property to a C# class using a code wizard in Class View only. Adding a property using the C# Property Wizard adds a property stub body to the class's .cs file, which you can then edit.
-> Properties can be made read-only. This is accomplished by having only a get accessor in the property implementation.
-> You can assign values to, but not read from, a write-only property. A write-only property only has a set accessor.

Static Properties: C# supports static properties, which belongs to the class rather than to the objects of the class. All the rules applicable to a static member are applicable to static properties also. Remember that set/get accessor of static property can access only other static members of the class. Also static properties are invoking by using the class name.

Properties & Inheritance: The properties of a Base class can be inherited to a Derived class. The inheritance of properties is just like inheritance any other member.

Properties & Polymorphism: A Base class property can be polymorphicaly overridden in a Derived class. But remember that the modifiers like virtual, override etc are using at property level, not at accessor level.

Properties & Abstractions: A property inside a class can be declared as abstract by using the keyword abstract. Remember that an abstract property in a class carries no code at all. The get/set accessors are simply represented with a semicolon. In the derived class we must implement both set and get assessors. If the abstract class contains only set accessor, we can implement only set in the derived class.

Auto-Implemented Properties:

This is where a property encapsulates a property with get and set accessors, without any other logic is common. It is more code than we should have to write for such a common scenario. That's why C# 3.0 introduced a new syntax for a property, called an auto-implemented property, which allows you to create properties without get and set accessor implementations.

public class Customer
public int ID { get; set; }
public string Name { get; set; }

In an auto-implemented property, the C# compiler creates the backing store field behind the scenes, giving the same logic that exists with traditional properties, but saving you from having to use all of the syntax of the traditional property.

Practical benefits of properties:

There are times when you could use non-private fields. However, there are still benefits to using properties even for trivial situations:

-> There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least).
-> Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
-> Want to log all access? Just add logging to the getter.
-> Properties are used for data binding in (WinForms and WPF); fields aren't.
-> In case you are designing a class library and the consumer is not under your control then add properties for all public fields to prepare for future needs to add checks to field access.
-> In case you can version (change) the client code as well, do not add properties just because its good, or because you think you might need functionality of checks, lazy loading in the future. In case you do not need these features right-away allow clients to directly use fields. With the new re factoring features of VS2005 changing all references to the field to properties is a non-issue.
-> With the above two filtering you are sure that once you have a property its definitely going to do some additional work and so only use the property from everywhere (including methods from same class).