Sign in to follow this  

[C#]What's the point of properties?

This topic is 3728 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

What is the point of doing this:
private int _var;

public int Var
{
      get { return _var; }
      set { _var = value; }
}

When I can just make a public variable? Does it run faster? Thanks in advance.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Properties are syntactic sugar.

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.

Share this post


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

Share this post


Link to post
Share on other sites
Properties are also automatically displayed on the PropertyGrid control. Further advantages include mixed permissions, like this:

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.

Share this post


Link to post
Share on other sites
If you can think of properties as being real variables/constants then you can also have values which are evaluated in a lazy manar without knowing externally the difference between those and others which are eagerly evaluated, e.g.:


public sealed class AABBTree {
// ....
public AABB Bounds {
get { if (isDirty) { RecomputeBounds(); isDirty = false; } return bounds; }
}
// ...
}

Share this post


Link to post
Share on other sites

This topic is 3728 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this