C# get/set/properties question
Author
Reading about C#'s auto-implemented properties, you can write a line such as:
public int ID { get; set; }
Can someone explain to me how this is useful? You can't place a breakpoint on that, so without that benefit, I might as well be using a public field... How is this better than the standard get/set like this:
private int m_id = -1;
public int ID
{
get
{
return m_id;
}
set
{
m_id = value;
}
}
???
Brevity, and because fields can't be used (and thus implemented as part of) interfaces. And because for a few select things, a property doesn't quite behave like a field, so refactoring from a field to a property (once you need to) isn't ideal.
In general though, the 'omg this is the best thing since sliced bread!' feeling I get from some about the feature is... overblown to say the least.
In general though, the 'omg this is the best thing since sliced bread!' feeling I get from some about the feature is... overblown to say the least.
Well... The first is shorter and is clear that it works like most properties do.
Also how likely are you to need to breakpoint the getter or a setter of the code you provided? Is there a very high likelihood that it will not work?
I feel it's sort of asking the question "Why do we have x++; when we have x = x + 1;?"
Also how likely are you to need to breakpoint the getter or a setter of the code you provided? Is there a very high likelihood that it will not work?
I feel it's sort of asking the question "Why do we have x++; when we have x = x + 1;?"
Its only use is less typing.
Why would you want to put a breakppoint at _field = value; ?
Changing public field to a set/get later on break or changes your interface because get/set are functions and a public field... well, it is just that.
Why would you want to put a breakppoint at _field = value; ?
Changing public field to a set/get later on break or changes your interface because get/set are functions and a public field... well, it is just that.
The standard reasoning behind using properties vs. fields is that you can change the internals of a property without breaking the public interface of your class. So even if you only need trivial access right now, using a property is just good future proofing.
Since it's recommended that you always use public properties, more and more language and API features are being developed around them as opposed to fields, with automatic properties being an example of one. They simply reduce the amount of code to get a trivial property implemented.
Since it's recommended that you always use public properties, more and more language and API features are being developed around them as opposed to fields, with automatic properties being an example of one. They simply reduce the amount of code to get a trivial property implemented.
Author
I think everyone may have misunderstood what I meant. I don't actually want to use a public field. I'm saying I don't see the point of the auto property because it seems to do exactly the same thing as just having a public field. The benefit of the get/set functionality is that you have a simple one-stop-shop for the altering of data (when it comes to debugging), and like you said, one place to change the functionality if you need to later. Yes, you can make it easier to rewrite the functionality later by expanding to a manually implemented property, however you still have lost the ability to debug the data field if you use this auto property. It just seems like a lazy/bad idea to me. Someone mentioned that you can use this in an interface, which does seem interesting, but then I just have to wonder why interfaces don't support their own members anyway... (this is coming from someone who has been working with C++ for years now BTW, if that helps you see my viewpoint).
Quote:Original post by TimptationBut a public property is not the same as public field.
I don't actually want to use a public field. I'm saying I don't see the point of the auto property because it seems to do exactly the same thing as just having a public field.
A number of things in the base class library (for example, the property grid control in WinForms and the XmlSerializer class) only work with properties. You could, perhaps, make the argument that these things should work with public fields as well as public properties, but that's a design decision that Microsoft has made.
If I had an auto-implemented property and I want to be able to put a breakpoint on the get/set, I'd just manually expand it out into a full property for the purpose of that debugging session.
Quote:Original post by Timptation
The benefit of the get/set functionality is that you have a simple one-stop-shop for the altering of data (when it comes to debugging)
That is a simple view of properties. Their primary benefit is looking and behaving like a field when in fact they're not backed by any (class) data.
Oh, and auto-properties allow for more easily specifying a 'field' that has different visibility levels for get/set. (just another benefit I forgot)
Quote:
but then I just have to wonder why interfaces don't support their own members anyway...
Because there's no good way to determine initialization order or virtual dispatch resolution of arbitrary multiple inheritance hierarchies in a nominative type system.
Author
I understand the difference between a field and a property. I guess this just comes down to "auto-properties reduce typing and improve readability", and my annoyance with having to rewrite/compile for a particular debug session. Maybe I'm comparing it to having to recompile a .h in C++, which can end up costing you a good amount of time if its included everywhere in a large project. My understanding is that C# is a bit better about that though...
edit- Oh, and the C++ example I'm thinking of is when a set function declaration and definition is written all on one line, so stepping never really gets the chance to enter the local scope, making it harder to debug. Thus, you have to expand the body vertically, meaning a recompile.
[Edited by - Timptation on February 19, 2010 12:42:31 AM]
edit- Oh, and the C++ example I'm thinking of is when a set function declaration and definition is written all on one line, so stepping never really gets the chance to enter the local scope, making it harder to debug. Thus, you have to expand the body vertically, meaning a recompile.
[Edited by - Timptation on February 19, 2010 12:42:31 AM]
One of the use of the auto complete property is to set the level of access from
another class or inherit.
Also if you drag the property to the watch window, it will automatic show the get value like:
A normal use is to create a class that inherit from List<> and then create a property with a "protected set" and a "public get" like the first example.
Edit: code tag add
another class or inherit.
//////Only the father class can modify the value///public int Count{ get; private set;}////// inherit class can modify the value///public int Count{ get; protected set;}Also if you drag the property to the watch window, it will automatic show the get value like:
public void Blabla(){MyClass c = new MyClass();c.Count; //drag this to the watch window}A normal use is to create a class that inherit from List<> and then create a property with a "protected set" and a "public get" like the first example.
Edit: code tag add
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement