I've learned about the getter and setter topic and i couldn't understand the new type of this topic :
Let's say someone is declaring a new get&set method :
public int Id { get; set; };
What i want to know is what is the differences between doing what i wrote below and a regular public variable (public int id).
Comments are welcome.
Properties enhance the notion of encapsulation in OOP (oject oriented programming). That's the of a getter and setter in C#. Concretely, instead of using a simple variable class, you could use a property and a backing field in which actually your value will be stored. The property would be the way to access this backing variable and get it's value or altered it. The good thing about properties is that you can use any logic you want, before you store the value the user provide you. So instead of doing the same check in the methods of your class where this value is setted by the user and then used you could use your property.
Let we have a class called Customer where, one of it's fields is the customer's age.
public class Customer
{
private int age;
public int Age
{
get
{
return age;
}
set
{
if(age>0)
{
age = value;
}
else
{
throw new ArgumentException("age must be greater than 0.");
}
}
}
}
Having defined the above property, you avoid the check of the age that will be provide by the creator of an object of type Customer in any other place. the provided value will be stored somewhere that the creator/consumer of the object should not know (encapsulation) and in general terms would make you life as a programmer far easier.
So you contructor now will not contain any logic:
public class Customer(int age)
{
Age = age;
}
you simply assign the provided value to the corresponding property, without making any check about the validity of the provided value in your constructor.
Furthermore, say that in a method of your class some calculations are executed and the result is going to stored to variable called age. If you use it's corresponding property, you will not have again to make any validation check. This was a rather simple case with one variable. Try to think about what would have happened if you had 6 or 7 variables, a common case in production code.
The above are applicable wherever you have variables, whose values setting requires validation. On the other, if you class holds only varaibles, whose values aren't to undergo a validation testing, you could use the following syntax.
public class Customer
{
public int Age { get; set; }
}
This syntax, at first seems meaningless. Why we should declare this instead of the following one:
public class Customer
{
public int age;
}
The second declaration doesn't respect the principle of encapsulation (for more information about encapsulation in OOP, please refer here. Namely, the second declaration exposes the variable in which we will actually store the value of age.
In a few words, it wouldn't happened anything odd if you had use the second declaration and not the first one - provided that's there weresn't any logic in you value setting. However it's more consistent you use the first one.
A public property keeps the option open to perform validation or other logic while getting or setting the value. A public field does not.
For example:
- You might want to check that an age value isn't negative or ridiciously high
- You might want to make sure that when a first name is set, that it is properly cased
If you offer these properties as public fields you won't be able to enforce these rules later on.
You can also use properties to perform lazy instantiation, which might be useful when working with resource intensive code.
