hi. my question i think is very simple and fast but really i dot know the answer.
in many classes i see they use a property like this:
int x{get;set;}
what really it does because most of the time i dont use it and there will be no problem.
thanks.
what really get and set do?
It is a shorthand in the language.
It creates a variable named x, and it creates a default mutator and accessor.
Mutators (set methods) allow the programmer to control access and specify additional behavior when the value is modified. The default one is x=value;.
Accessors (get methods) allow the programmer to control or modify behavior when the value is read. The default one is return x;
You can add more complete get and set bodies later, if you have reason to specify additional behavior.
It creates a variable named x, and it creates a default mutator and accessor.
Mutators (set methods) allow the programmer to control access and specify additional behavior when the value is modified. The default one is x=value;.
Accessors (get methods) allow the programmer to control or modify behavior when the value is read. The default one is return x;
You can add more complete get and set bodies later, if you have reason to specify additional behavior.
By making x into a property, you prevent it from being used as a reference parameter.
I personally don't see much of the point in auto-implemented properties in C#. When I first saw C# had properties, I thought the whole point was to make something that had the same syntax as a public member variable, so for refactoring purposes you could easily switch between the two choices. In my opinion, that should have made public member variables more acceptable. I guess that didn't happen, which could be why this was added into C# in version 3.0.
the basic type foo {get;set;} is mostly not that great, unless you want to refactor later and change have the property do something else (like raise an event when changed or something). But the syntax does let you do things like type foo {get; private set;}, which I like as a fairly nice way of having a public facing readonly property without a second member variable declaration.
EDIT: Oh and C#6.0 has type foo {get;} which makes a readonly property. http://www.c-sharpcorner.com/UploadFile/a20beb/getter-only-auto-properties-in-C-Sharp-6-0/
the basic type foo {get;set;} is mostly not that great, unless you want to refactor later and change have the property do something else (like raise an event when changed or something). But the syntax does let you do things like type foo {get; private set;}, which I like as a fairly nice way of having a public facing readonly property without a second member variable declaration.
Yes, I was commenting on the typical usage of just putting "{get; set;}" on the end of variables. There are some more useful things you can do with the syntax - access restriction and overriding inherited properties are both possible. But doing it just to refactor later makes little sense to me, unless you are really concerned that your variable will be used in reference parameters everywhere. You can refactor from a variable as well. You don't have to start with a property to be allowed to refactor something.
You don't have to start with a property to be allowed to refactor something.
No, but it is worth noting (in the general sense and to the OP) that a property isn't a field (although one might be involved behind the scenes): you find them differently via reflection. So if reflection ever might be involved, it's a consideration in whether to start with a field or a property since the distance from field to property-with-custom-getter-or-setter is larger than property-with-trivial-getter-and-setter to property-with-custom-getter-or-setter. If only slightly.
For this reason I generally always use properties, and rarely public fields. The inability to reference the property has never been a serious issue in any of the code I've written anyway.
By making x into a property, you prevent it from being used as a reference parameter.
I personally don't see much of the point in auto-implemented properties in C#. When I first saw C# had properties, I thought the whole point was to make something that had the same syntax as a public member variable, so for refactoring purposes you could easily switch between the two choices. In my opinion, that should have made public member variables more acceptable. I guess that didn't happen, which could be why this was added into C# in version 3.0.
Properties carry different semantics to fields, have different reflection entry points, access protection and the like.
I would say it is normally better the use properties for access/manipulation than public fields even though they look the same syntax to access on the surface. With auto properties it also carries no real syntax overhead compared to the old days where you required backing fields and at some point when refactoring etc you will say, "If only it were a property" which could be a painful refactor :)
You also have the following difference
public class MyThing
{
public readonly int Value1;
private readonly int _value2;
public MyThing(int value1, int value2)
{
Value1 = value1;
_value2 = value2;
}
public int Value2 { get {return _value2; }}
}
When you get Value1 it is a direct access to the value type but when you get Value2 it is a copy of the value type.
That said, if you are working in Unity forget all of this because that engine prefers you have public fields or you class does not play nice with the editor etc
Fields are really not properties.
They look similar, but under the hood a field is a piece of data and a property is really a collection of functions.
public class Thing
{
public int x;
}
really is exactly what it says on the tin, but
public class Thing
{
public int X {get;set;}
}
is more like
public class Thing
{
private int _x;
public int get_X() { return _x; }
public void set_X(int value) { _x = value; }
}
in fact, if you fire up Reflector*, that's exactly what you'll see.
.property instance int X
{
.get instance int MyNamespace.Thing::get_X()
.set instance void MyNamespace.Thing::set_X(int)
}
*you do have reflector, right? I mean, you'd be insane to do .net development without it.
Here's another approach:
public String CharName { get; private set; }
Which allows public return, but prohibits assigning outside the class.
Get/Set is just a quick 'macro'. It basically points to a data type in a class/struct.
public String CharName { get; private set; }
Which allows public return, but prohibits assigning outside the class.
Get/Set is just a quick 'macro'. It basically points to a data type in a class/struct.
Get/Set is just a quick 'macro'. It basically points to a data type in a class/struct.
I'd be wary of using the terms "macro" and "points to". I understand what you're trying to say, but those terms have a very specific meaning and properties are neither macros nor pointers.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
