private int _var;
public int Var
{
get { return _var; }
set { _var = value; }
}
[C#]What's the point of properties?
Author
What is the point of doing this:
When I can just make a public variable? Does it run faster?
Thanks in advance.
There's no point doing that, as such. However, later on you might want to have a more complex get or set method. eg. You might want a set that clamps values to a valid range. Or you might decide that you can't store the value but will calculate it on the fly based on other values. Or maybe the get will be cached and you need to invalidate the cache with the set. The benefit of using properties is that you can implement any or all of these ideas later, but it still looks just like a public variable to the calling code.
For a simple property like that, the property access is inlined in a release build so it is just as fast.
The point of properities is mainly seperating data access interfaces from data storage. You might not store the int in a var like that, you might hold it in a view state, or it might be stored as a double internally but exposed as an int.
The point of properities is mainly seperating data access interfaces from data storage. You might not store the int in a var like that, you might hold it in a view state, or it might be stored as a double internally but exposed as an int.
In a more general sense, the point of properties is to reduce coupling.
When a consumer of a class uses an instance variable of the class directly, the consumer is directly coupled to the implementation of the class's instance variable. If you change the type of the variable, the consumer has to be inspected and possibly updated. If you change the name of the variable, the consumer has to be updated. If you want extra behavior attached to setting this variable, you can't do it without a property since you can't intercept the assignment to the instance variable. If you want to dynamically compute the value instead of just storing it, you can't do this without the property since you can't intercept the access (reading) of the instance variable. If you want to extract an interface from a class, you can't put instance variables in the interface, only properties.
For all of these reasons, and probably some more that I'm not remembering off the top of my head, its wise to never expose instance variables of a class to the consumers of that class, but instead use a property or getter/setter methods.
When a consumer of a class uses an instance variable of the class directly, the consumer is directly coupled to the implementation of the class's instance variable. If you change the type of the variable, the consumer has to be inspected and possibly updated. If you change the name of the variable, the consumer has to be updated. If you want extra behavior attached to setting this variable, you can't do it without a property since you can't intercept the assignment to the instance variable. If you want to dynamically compute the value instead of just storing it, you can't do this without the property since you can't intercept the access (reading) of the instance variable. If you want to extract an interface from a class, you can't put instance variables in the interface, only properties.
For all of these reasons, and probably some more that I'm not remembering off the top of my head, its wise to never expose instance variables of a class to the consumers of that class, but instead use a property or getter/setter methods.
Additionally, properties can be virtual (if I remember correctly) since they're just functions, and thus can function polymorphically, depending on what the underlying type of an instance is, whereas public members cannot do this at all.
Another way to look at it is that properties allow you to switch from using a variable to a function and back without changing all the code that uses the class.
Properties are syntactic sugar.
Without them, you do it like this:
In some environments, most notably RAD, interface-based applications, and other meta-level frameworks, the notion of a variable alone becomes insufficient. As such, a set of support constructs needs to be provided to take care of house-keeping and public access.
Properties are one of these mechanisms. Serialization/marshalling is another. And on top of that, garbage collection and reflection.
When all of these are coupled together, they allow a fully automatic, robust, unambiguous and very high-level, language independent access to big building blocks.
Many languages and tools support such abstractions, since they usually simplify the definitions and help hide as much functionality as possible, and allow for high-level interface definitions.
Int property by itself really isn't much. But as you scale applications, you quickly come to conclusion that abstracting all internal functionality in a common way is quite useful.
Without them, you do it like this:
...int value;void setValue( int v );int getValue();In some environments, most notably RAD, interface-based applications, and other meta-level frameworks, the notion of a variable alone becomes insufficient. As such, a set of support constructs needs to be provided to take care of house-keeping and public access.
Properties are one of these mechanisms. Serialization/marshalling is another. And on top of that, garbage collection and reflection.
When all of these are coupled together, they allow a fully automatic, robust, unambiguous and very high-level, language independent access to big building blocks.
Many languages and tools support such abstractions, since they usually simplify the definitions and help hide as much functionality as possible, and allow for high-level interface definitions.
Int property by itself really isn't much. But as you scale applications, you quickly come to conclusion that abstracting all internal functionality in a common way is quite useful.
Using the property to set a private variable then you have a great place to test to make sure the data is valid before set the variable.
From my experience some of the most problematic error are data errors. When you don't verify you have good data you can get some very unexpected results.
theTroll
From my experience some of the most problematic error are data errors. When you don't verify you have good data you can get some very unexpected results.
theTroll
Properties are also automatically displayed on the PropertyGrid control. Further advantages include mixed permissions, like this:
Also, C#3 adds automatic properties, so you can just do this (so there's no excuse to use a property):
Another advantage is that interfaces can expose properties.
public int SomeProperty { get { return this.someProperty; } internal set { this.someProperty = value; }}Also, C#3 adds automatic properties, so you can just do this (so there's no excuse to use a property):
public int SomeProperty { get; set;}Another advantage is that interfaces can expose properties.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
