Why use properties?

  • Thread starter Thread starter Janaka
  • Start date Start date
J

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=value;}
}
 
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.
 
Janaka said:
However why is it necessary to create a property if a public member
variable will do.
Click to expand...

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
 
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(value)
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;
CalculateNewIncome();
PayTaxes();
ReportToSupervisor();
}
}

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(salesTotal);
}
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(salesTotal.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.
 
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.
Click to expand...

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.
 
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.
 
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.
 
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=value;}
}

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
 
Saying
Click to expand...

is better than
Click to expand...

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.
Click to expand...

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.
 
James Curran said:
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.
Click to expand...

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.
 
However why is it necessary to create a property if a public
member variable will do.
Click to expand...

You can then use GetType().GetProperties() to dynamically discover the
properties a type supports - think property grids in the VS designer.

If something is conceptually a property, it is better to implement it as a
property. Implementing some of your properties as fields and some as
properties would be inconsistent.

This issue also touches on the whole "Component Oriented Programming" thing
that was one of the founding principles of C#.

Mark
 
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.
Click to expand...

But... Are we changing the interface? If a class user were to write
myObject1.SalesTotal = 100.00f;
it's irrelevant to him if SalesTotal is implemented as a public variable or
as a property. Nor will he notice if it's changed. (though he will have to
recompile)

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
James,

And that's the key. While the developer might not notice while writing
code, if they are part of the build process, they definitely will know (and
any good developer is at least compiling and testing this stuff on their
own). =)


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

James Curran said:
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.
Click to expand...

But... Are we changing the interface? If a class user were to write
myObject1.SalesTotal = 100.00f;
it's irrelevant to him if SalesTotal is implemented as a public variable
or
as a property. Nor will he notice if it's changed. (though he will have to
recompile)

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
Click to expand...
 
James said:
it's irrelevant to him if SalesTotal is implemented as a public variable or
as a property.
Click to expand...

No. For instance properties can't be passed by reference.

Christian
 
James Curran said:
But... Are we changing the interface? If a class user were to write
myObject1.SalesTotal = 100.00f;
it's irrelevant to him if SalesTotal is implemented as a public variable or
as a property. Nor will he notice if it's changed. (though he will have to
recompile)
Click to expand...

Exactly - he'll have to recompile. It keeps the interface mostly the
same as far as the source code is concerned (see Christian's post for
an example of it breaking even that) but the interface will change at
the metadata level. That might also affect people using reflection, as
well as demanding a recompilation.
 
James Curran said:
But... Are we changing the interface? If a class user were to write
myObject1.SalesTotal = 100.00f;
it's irrelevant to him if SalesTotal is implemented as a public variable or
as a property. Nor will he notice if it's changed. (though he will have to
recompile)
Click to expand...

but can you require all production code be recompiled to your changes? I
think that's rather unrealistic.
 
Janaka said:
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=value;}
}
Click to expand...

And we got sensible answers, in particular: if you later have to change your
public member variable into a property because get and set become more
complex, you'll have to recompile all calling code.

And, to have your code consistend, you should not mix properties and public
member variables.

OK, so it makes sense to use properties. But why are public member variables
even allowed then? What might be a reason to consider using them?

Joachim
 
Here is the rule of thumb we use:

- If a public instance member in an assembly, especially one to be reused by
outside users, always go for a property.

- If an internal Type in an assembly, determine if there are some good
reasons before making a property (error checking, centralization of logic
are good reasons). These will be compiled every time anyway, so the
"recompile" argument doesn't hold.

- If a private Type only used by one other enclosing Type, prefer a public
field, unless there is some other good reason (centralization of logic).
This is the most likely situation where you might use a public field, for
example on an internal lightweight struct definition. The struct used as a
hashtable bucket is a good example.

- Static readonly data may be faster if presented as a public const field.

So there are uses for public fields. If you don't need a property, you can
save a bit of code. But the uses are rare.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor
 
But the question was, "what's the advantage of a property if all I need (for
now) is simple assignment?".

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

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.
Click to expand...

Can you do it so easily? You are thinking in a very closed minded manner.
Do you assume that everyone who uses your class will be a language that
hides the actual get/set methods of a property behind direct access? Yes,
in C# if you code a property with a get and set then you can access that
directly via Class.Property. Not all languages support that. In some that
may appear instead as Class.get_Property and Class.set_Property. You will
have already forced a recompile of anyone who uses your object. For those
using a language other than C# or VB you may have also forced them to
change their code. Good design dictates encapsulating access to member
variables through properties. The amount of extra work is extremely small
and the payoff in maintenance is potentially substantial.

Along the same lines I have seen recommendations that you should never
write a public constructor for any of your objects. You should leave the
constructor of your object private, and add a static method that returns an
instance of your object. This would mean that anyone who uses your object
would have to ask you specifically for that instance. The reasoning for
this is again to protect against future modifications that you can not
anticipate today. For example, possibly in some future scenario you end up
with several forms of your object, each coded for a variation of the
scenario for which the first was coded. By coding a method that returns an
instance of your object rather than allowing it to be created directly you
now have control of which variation of your object to return. If the
variations get rather numbered, you can easily delegate the instance
creating method to a factory object that at initial development was not
even considered.

Food for thought.
 
Back
Top