Jump to content
  • Advertisement
Sign in to follow this  
Timptation

C# get/set/properties question

This topic is 3070 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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; } } ???

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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;?"

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Quote:
Original post by Timptation
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.
But a public property is not the same as 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
One of the use of the auto complete property is to set the level of access from
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!