What is this blog post for?
This is the first post from my new series – Basics. In this series I will add things which are (in my opinion) really important and should be perfectly known by every Developer/Senior. I will add topics which I have been asked for or things which I have expected to be known by the mass, but it wasn’t that case. I will try to be as much platform independent as possible. Of course I will add some general knowledge about new things in C# 3.0. I will try to be as much detailed as possible but will appriciate any help/comments on making things broader. No matter – lets go back to basics!
This post is for the so called accessors and mutators / getters and setters / get and set methods / properties in C# / etc. and why we need them at all?
The explanation
public class Person
{
public int age;
}
public class Person
{
private int age;
public int getAge()
{
return age;
}
public int setAge(int value)
{
age = value;
}
}
Firstly, accessors and mutators are used mainly for encapsulating fields of a class (an example for different usage can be given for storing information in the Session or ViewState). It’s not good practice to expose public fields (or why it is better to use getters and setters), because:
- If you use get and set method, you are able to control the access of the property. For example you can give public get and protected/private/etc. set.
- You can put any kind of validation in the set method. If there is a need you can throw an exception.
- The situation may need to set other dependant properties, too, when accessing/setting the current one.
- When you access the get/set method you can rise an event (for example OnValueChanged)
- You can convert the value which you return from the getter to more informationless data (for example you can have a value for a price and you want to return it with 2 digits after the decimal point, but in your calculations it should be as much digits as possible for more correct calculations).
- It is easier to bind against proeprties.
- If you expose public fields, later you cannot change them into properties without recompiling.
Still why?And yet again – why to use getters and setters when we have just a simple integer field which we do not think will need any special work now? Why should I “loose” my time writing additional code? Because in our everyday life almost every time the specification is changed and almost every time there is a situation which we didn’t take in mind at the time of writing the code. In general in my opinion a good developer is the one that can write as much extensible code as possible, as much reusable as possible and as easier to change as possible nomatter which platform is used. The practice of using getters and setters gives you the flexibility to be the winner in the battle between you and the changing specification. It gives you a very simple rule of a thumb which makes your code keeping tight encapsulation.
Something in addition for C# 3.0Yes – one of the greatest things in C# (compared to Java for example) is its properties. In Java you do not have such structure (as I have heard this is going to be changed in some of the future releases of Java. I will just ask - where are my get* and set* methods!?!?!). Most of the code one will see in an average Java program is a bunch of getters and setters (hopefully generated).
In C# we have the chance to work with this more clear structure called property. However in C# 1.1 there was a little problem – there was no way in which you can say “I want to have a public getter and a private setter”. The only ability was to say whether you want to have get and/or set with an one and the same access modificator.
In C# 2.0 we were given the access modification functionality for each of the two property parts. This was great. But there was still something which missed me all the time – I wanted to have a way to enforce everybody to use the property and not the field (in general this has sense if you think about the access of the field in the class in which it is defined). Here the C# 3.0 come one day and say “I can fix this!” The magic is called Automatic properties. See the following example which shows an automatic property:
int Age
{
get;
set;
}
As you can see we do not need to explicitly define field for this property. What actually happens is that when the C# 3.0 compiler see an empty get/set property it will automatically generate a private field for you. This means – less code to write and more to generate. Another effect is the fact that you cannot directly access the fields which solves the problem mentioned above.
Conclusion:Just think of all the mentioned things in the above post. You as developer can only benefit from this. If you didn’t find any sense of using getters/setters, to be honest with you - just find a better field for you.
P.S. If you want to get more information on automatic properties and what happens under the covers you can go to
Bart De Smet Blog.
I am very much exited to share with you the news of a coming Java event which we are preparing these days at NASD along with our partners from Insight_technologies – Java2Days!
