I see this all the time:
private int _myint; public int MyInt { get { return _myint; } set { _myint = value; } } To me this seems identical to:
public int MyInt{ get; set; } So why does everyone do the former... WHY THE PRIVATE VAR AT ALL?!
- 7There's a private variable in both cases, however in the second case it is generated by the compiler.Brian Rasmussen– Brian Rasmussen2010-02-12 19:30:50 +00:00Commented Feb 12, 2010 at 19:30
Add a comment |
9 Answers
First of all, this is new to C# 3.0, it wasn't around before that. Second, if you want to add any custom logic to your getter and setters, you have no choice. So yes, in your example where there's no custom logic, it's the same thing (in fact the compiler generates that for you behind the scenes) but if you want to raise an event for example, or anything like that, you have to be explicit about it.
1 Comment
Dave
perfect example of what BFree is referring to for events is in MVVM, where you need to raise PropertyChanged to make the GUI reflect the new databinding value.
I'd like to see
public int MyInt{ get; private set; } more, ;)
but @BFree nailed it
4 Comments
herzmeister
well how would i do the "private set" then in that class?
Steve
@hdw - you can set it in the class, you just can't set it from outside the class.
Steve Mitcham
I use that pattern a lot in the case of classes where I have 'dump properties'; however, as mentioned in other responses, the automatic property precludes any custom logic that may need to occur during the get or set.
Ed Power
I use this when I want to set something internal to the class but have it appear as read-only externally.
An example to expand on what @BFree is saying:
private int _Whatever; public int Whatever { get {return _Whatever;} set { if(value != _Whatever) { // It changed do something here... // maybe fire an event... whatever } _Whatever = value; } } 
Comments
First of all, the syntax you used is new. It didn't exist in earlier versions of C#.
Second of all, you need the private variable if you're going to have a default value, or lazy-load the result.
Comments
Do you like someone you don't know messing with your private parts? I hope not. This is a way to provide what is essentially a proxy for something you own but don't want to cede control over. If you decide you want to validate that int's are positive, you can start doing that if you code as shown.
C# makes this transparent now with automatic properties.
answered Feb 12, 2010 at 19:14
No Refunds No Returns
8,4464 gold badges36 silver badges44 bronze badges
Comments
Before C# 3, that was the only way to do it. Implicitly typed properties were not yet available. People still wanted to abstract away the private member. If developers are still doing this in C# 3, they either aren't aware of the new changes or need to provide custom get/set logic.
Comments
That's the old way to do it. The way you prefer ("automatic properties") it a relatively new construct in the language. A few years ago, we always had to use private variables.
There may be other reasons to use private variables as well, though not in the simple example you provide. If, for example, you needed to intialize the property with a default value, you can't really do that cleanly with automatic properties; instead you need to initialize in the constructors.
Comments
public int MyInt{ get; set; } was a feature added in C# 3.0 called Automatic Properties. C# 2.0 does not support this and requires the private variable with the explicit getters and setters. Therefore, a lot of older code or backwards compatible code will use the explicit getters and setters.
Comments
If you look at the output produced by the compiler with a tool like reflector a private field has been added
