Fields Vs Properties
In .NET, we can define attributes of a class as a field like:
public class Employee
{
private System.Int32 employeeId = 0;
...
}
And if, we want this attribute to be accessed by other clasess, we make it public like :
public System.Int32 EmployeeId = 0;
We, also have an alternate way of declaring the same thing, as a property like:
public class Employee
{
private System.Int32 employeeId = 0;
public System.Int32 EmployeeId
{
get { return employeeId ; }
set { employeeId = value; }
}
}
Now, EmployeeId is a property, which is exposed to other classes.
We can think and figure out the difference between the two approaches - of defining it as a public field or a property.If we declare the attribute as a property , we can go ahead and modify the get-set section like:
public class Employee
{
private System.Int32 employeeId = 0;
public System.Int32 EmployeeId
{
get
{
return employeeId ;
}
set
{
if (value>0)
{
employeeId=value;
}
}
}
}
What is being done here is, by writing some code in get-set method of a property, we can control the access to the property.Property acts as a gatekeeper.
Another advantage, lets take a scenario that tomorrow you have a scenario, where you want to remove employeeId and have some other field.Now if you had declared the attribute as public field ,this would have resulted in breaking of existing components accessing it. But since it is declared as a property we can go ahead and easily do it, without breaking any existing components, like:
public class Employee
{
private System.Int32 empId =100;
public System.Int32 EmployeeId
{
get
{
return empId ;
}
set
{
empId =value;
}
}
}
First example depicts DataHiding and the second one depicts versioning.
And, this is what msdn says about properties:
"You should expose properties instead of public fields from your components, because properties can be versioned, they allow data hiding, and the accessor methods can execute additional logic.Generally, because of just-in-time optimizations, properties are no more expensive than fields."
public class Employee
{
private System.Int32 employeeId = 0;
...
}
And if, we want this attribute to be accessed by other clasess, we make it public like :
public System.Int32 EmployeeId = 0;
We, also have an alternate way of declaring the same thing, as a property like:
public class Employee
{
private System.Int32 employeeId = 0;
public System.Int32 EmployeeId
{
get { return employeeId ; }
set { employeeId = value; }
}
}
Now, EmployeeId is a property, which is exposed to other classes.
We can think and figure out the difference between the two approaches - of defining it as a public field or a property.If we declare the attribute as a property , we can go ahead and modify the get-set section like:
public class Employee
{
private System.Int32 employeeId = 0;
public System.Int32 EmployeeId
{
get
{
return employeeId ;
}
set
{
if (value>0)
{
employeeId=value;
}
}
}
}
What is being done here is, by writing some code in get-set method of a property, we can control the access to the property.Property acts as a gatekeeper.
Another advantage, lets take a scenario that tomorrow you have a scenario, where you want to remove employeeId and have some other field.Now if you had declared the attribute as public field ,this would have resulted in breaking of existing components accessing it. But since it is declared as a property we can go ahead and easily do it, without breaking any existing components, like:
public class Employee
{
private System.Int32 empId =100;
public System.Int32 EmployeeId
{
get
{
return empId ;
}
set
{
empId =value;
}
}
}
First example depicts DataHiding and the second one depicts versioning.
And, this is what msdn says about properties:
"You should expose properties instead of public fields from your components, because properties can be versioned, they allow data hiding, and the accessor methods can execute additional logic.Generally, because of just-in-time optimizations, properties are no more expensive than fields."
Comments