[RESOLVED] Why use Properties?

Hi,

I was just thinking for a reason (good, sound reason), why do we need to implement Properties, or any kind of 'Get'ers and 'Set'ers.

Just because it conforms to OOP way of programming is something not reasonable (at least to me). Suppose if the same question is put to you while you are being interviewed, what do you guys suppose could answer the question in succinct manner?

How does it help? How does it help in future development? When we say it is secure, how is it secure? If it is efficient, how so?

Hope I am being clear.

Thank you

What else would you use?

-tg

What harm in using the variable itself?

Edit: I mean why can't we make variables public and use them?

In short, there's no reason... I don't know what the bindability of public vars is... I'm pretty sure they don't show up as "Properties" for custom controls (in the Properties window in the designer) nor am I sure how they are serializable (if they are) aaaaand, you can't make them read only.... or write only. And you can't run code when a variable is set like you can with a property. Properties make it easier to add validation and stuff.

-tg

Thanks for the answer tg. Makes sense.

I am keeping this thread open, just in case someone wants to add more points.

Edit: Sorry, can't rep you. Need to spread some reputation points before. But thank you.

I think the basic idea is that you can protect the data it is supposed to hold. It's one thing when you are developing everything, but if you are to develop one piece of code and then someone is to develop the other, the other guy might not know the limitations imposed on a certain variable. Let's say you have a property called Age and it's an Integer. If it was a variable the other dude could set it to -5 and screw up a lot of things. With a property you can check the value passed to see if it meets the required parameters. That way you ensured that the (private) variable can not be put into an invalid state.

It really comes down to one thing: fields are just data while properties can contain logic associated with that data. The two most common forms that logic takes are validation and events. There's also the fact that you can make a property ReadOnly. A field can be ReadOnly too, but then that literally means that its value can't change. A ReadOnly property can't be set externally but the value of its backing field can change internally. Basically the same reasons provided in every one of the many other threads that already exist on this topic.

Thank you guys.

Edit: Sorry JMC, can't add to your rep too. But thank you.

Quote:

---

Originally Posted by techgnome

In short, there's no reason... I don't know what the bindability of public vars is... I'm pretty sure they don't show up as "Properties" for custom controls (in the Properties window in the designer) nor am I sure how they are serializable (if they are) aaaaand, you can't make them read only.... or write only. And you can't run code when a variable is set like you can with a property. Properties make it easier to add validation and stuff.

-tg

---

Use accessor methods instead example:

c# Code:

frmSummary summary = new frmSummary();
//Assign accessor values
summary.var ="Something";
Summary.ShowDialog();

then in the Second form

c# Code:

private type data variable
public type var{
set{
data variable = value;
}
}

Then in form_load (or whereever):

c# Code:

Set the object ie a textbox.text = variable;

That is what I have been taught to do in order to make the program more secure.

Quote:

---

Originally Posted by Nightwalker83

Use accessor methods instead example

---

You just provided an example of using a property. Those accessor methods are the property getter and setter. A property bundles a get and set method and makes them appear to the outside world to behave just like a field, which is a nicer option than Java where you just write two methods with "get_" and "set_" prefixes.

Quote:

---

Originally Posted by jmcilhinney

You just provided an example of using a property. Those accessor methods are the property getter and setter. A property bundles a get and set method and makes them appear to the outside world to behave just like a field, which is a nicer option than Java where you just write two methods with "get_" and "set_" prefixes.

---

Ah ok.

Here's a few reasons:
http://blogs.msdn.com/b/vbteam/archi...han-aneja.aspx
There are even more, such as being able to call events in the setter and the fact that properties show up in the designer where fields do not.

I linked to this webpage at least 3 times already :p

Want to know something funny, if you look at the IL emitted from your application you will see that the property you make is actually just a set of get()/set() functions when it boils down to it.

Having said that, they are wired into the framework so don't go using get/set methods instead of properties.