Why use properties?

[Janaka]

I'm having a discussion with my colleagues here on good programming
standards. One thing we haven't agreed on is the use of properties in
classes vs using member variables. Now everyone knows that it is useful to
use a property when it has to do some further action on the data such as
private double salesAvg;
public double SalesAverage
{
set {
salesAvg = value / salesTotal;
}
get {
return salesAvg;
}
}

However why is it necessary to create a property if a public member variable
will do. For example:
public int SalesTotal;

rather than

private int salesTotal;
public int SalesTotal
{
get {return salesTotal;}
set {salesTotal=val ue;}
}

[Nicholas Paldino [.NET/C# MVP]]

Janaka,

The best case I can think of is that you won't break your profile (which
can be a pain) when the time comes to add functionality. It's much easier
to just do this from the get go (and with the snippet template for
properties in VS.NET 2005, there is really no reason to not do it).

Ultimately, it takes control away from the developer and increases the
maintinence of this kind of code. For example, what if you derived from
this class and wanted to do some processing while setting the field?

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"Janaka" <ja*****@hotmai l.com> wrote in message
news:OG******** ******@TK2MSFTN GP15.phx.gbl...

I'm having a discussion with my colleagues here on good programming
standards. One thing we haven't agreed on is the use of properties in
classes vs using member variables. Now everyone knows that it is useful
to use a property when it has to do some further action on the data such
as
private double salesAvg;
public double SalesAverage
{
set {
salesAvg = value / salesTotal;
}
get {
return salesAvg;
}
}

However why is it necessary to create a property if a public member
variable will do. For example:
public int SalesTotal;

rather than

private int salesTotal;
public int SalesTotal
{
get {return salesTotal;}
set {salesTotal=val ue;}
}

[Christian Gudrian]

Janaka schrieb:

However why is it necessary to create a property if a public member
variable will do.

Publicly available member variables can be changed by anyone anytime
without the class or one of its instances taking notice about this. One
principle of OOP is the encapsulation of data.

In my class designs member variables are always declared as private.
Even descendant classes need to access my members via appropriate
properties so that the base class knows exactly what is being accessed.

Christian

[Morten Wennevik]

Hi Janaka,

There are several reasons why properties is better than public variables.
1. It lets you filter what is entered, safeguarding against unsupported
values.

private int salesTotal;
public int SalesTotal
{
get
{
return salesTotal;
}
set
{
if(Reasonable(v alue)
salesTotal = value;
}
}

2. It lets you hide what actually happens (acting like a method), all the
user has to worry about is setting SalesTotal.

private int salesTotal;
public int SalesTotal
{
get
{
return salesTotal;
}
set
{
salesTotal = value;
CalculateNewInc ome();
PayTaxes();
ReportToSupervi sor();
}
}

3. Changes to the internals of the class won't affect any external use of
the property.

private STRING salesTotal;
public int SalesTotal
{
get
{
try
{
return Int32.Parse(sal esTotal);
}
catch
{
return 0;
}
}
set
{
salesTotal = value.ToString( );
}
}

4. Gives you a clean way to set and get user control values.

private TextBox salesTotal;
public int SalesTotal
{
get
{
try
{
return Int32.Parse(sal esTotal.Text);
}
catch
{
return 0;
}
}
set
{
salesTotal.Text = value.ToString( );
}
}

In effect, hiding the internal code is always good.
While there isn't much reason to use a property when you aren't doing
anything to the variable it is still smart to use it since you may never
know what you will do in the future.

--
Happy Coding!
Morten Wennevik [C# MVP]

[Tom Porterfield]

On Fri, 3 Dec 2004 15:18:03 -0000, Janaka wrote:

I'm having a discussion with my colleagues here on good programming
standards. One thing we haven't agreed on is the use of properties in
classes vs using member variables.

However why is it necessary to create a property if a public member variable
will do.

In short, maintenance. Can you be absolutely sure that your member will
never need any type of manipulation either when being retrieved or when
being set? What if at some future time a requirement is added that the
member variable must be greater than 0. Would you not want to validate
that as soon as the value was set, not even allowing an invalid value? How
are you going to do that if anyone can set that member directly whenever
they wish? Or what if the value had to always be rounded to a multiple of
10. Would you want to have to do that in every place that read the value
of the variable, or would you rather code that in one place so that
everyone who read the value automatically got it rounded appropriately? By
encapsulating that member variable in get/set methods, you have protected
your code from future changes. This is good design.
--
Tom Porterfield

[Harshad Rathod]

Another reason is that you can leverage on PropertyChanged event, very
useful. You can then propogate chain reaction to many listners to your
control.

Harshad.
"Janaka" wrote:

I'm having a discussion with my colleagues here on good programming
standards. One thing we haven't agreed on is the use of properties in
classes vs using member variables. Now everyone knows that it is useful to
use a property when it has to do some further action on the data such as
private double salesAvg;
public double SalesAverage
{
set {
salesAvg = value / salesTotal;
}
get {
return salesAvg;
}
}

However why is it necessary to create a property if a public member variable
will do. For example:
public int SalesTotal;

rather than

private int salesTotal;
public int SalesTotal
{
get {return salesTotal;}
set {salesTotal=val ue;}
}

[Janaka]

Thanks for all the replies.

I believe the main reason why to code in a skeleton property with just a
get/set is to provide future-proofing and easier maintenance in the long
run.

Tom your reply was even approved by our head sceptic.

"Janaka" <ja*****@hotmai l.com> wrote in message
news:OG******** ******@TK2MSFTN GP15.phx.gbl...

I'm having a discussion with my colleagues here on good programming
standards. One thing we haven't agreed on is the use of properties in
classes vs using member variables. Now everyone knows that it is useful
to use a property when it has to do some further action on the data such
as
private double salesAvg;
public double SalesAverage
{
set {
salesAvg = value / salesTotal;
}
get {
return salesAvg;
}
}

However why is it necessary to create a property if a public member
variable will do. For example:
public int SalesTotal;

rather than

private int salesTotal;
public int SalesTotal
{
get {return salesTotal;}
set {salesTotal=val ue;}
}

[James Curran]

Funny thing is --- I was just about to post a very similar question to the
group.

However, I'm still a bit more skeptical. Of all the answers given, only
Nicholas's held water.

All the rest boil down to, "You need a property -- if you need more than
simple assignment."

But the question was, "what's the advantage of a property if all I need (for
now) is simple assignment?".

Saying
private int salesTotal;
public int SalesTotal
{
get {return salesTotal;}
set {salesTotal=val ue;}
}

is better than

public int SalesTotal;

because I might want to change the get/set at some time in the future is a
false lead, as I could convert the latter into the former at any time.
Basically, it comes down to doing more typing now, to potentially save the
same amount of typing later. By the same principle which leads us to
lazy-loading information from databases, would lead us to prefer the public
variable until such time as we need to convert it to a Property.
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
"Janaka" <ja*****@hotmai l.com> wrote in message
news:ew******** ******@TK2MSFTN GP12.phx.gbl...

Thanks for all the replies.

I believe the main reason why to code in a skeleton property with just a
get/set is to provide future-proofing and easier maintenance in the long
run.

Tom your reply was even approved by our head sceptic.

public int SalesTotal;

rather than

private int salesTotal;
public int SalesTotal
{
get {return salesTotal;}
set {salesTotal=val ue;}
}

[Jon Skeet [C# MVP]]

James Curran <Ja*********@mv ps.org> wrote:

<snip>

Saying
<snip - property code>
is better than
<snip - field code>
because I might want to change the get/set at some time in the future is a
false lead, as I could convert the latter into the former at any time.

Yes, so long as you don't mind the change in interface. That's the key
thing - do you want to maintain interface compatibility as far as
possible, or not? I like to on principle, personally.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Paul E Collins]

"James Curran" <Ja*********@mv ps.org> wrote:

Saying
[private field and accessor property]
is better than
[public field]
because I might want to change the get/set at some time
in the future is a false lead, as I could convert the latter
into the former at any time.

It might not be that simple, though. Such a change affects your
interface and forces anything using it to be recompiled. Also consider
cases with 'ref' and 'out' parameters, where using a property may not
be valid.

P.