Use properties or variables in class

[John Baro]

I have a class as:

public class a :
{
private float m_b;

public float b
{
get
{
return m_b;
}
set
{
m_b = value;
}

public float compute()
{
//*************** *************** *************** ********
//This method
return m_b * 369871;
//*************** *************** *************** ********
//Or this method
return b * 369871;
//*************** *************** *************** ********
}
}

What are peoples thoughts on the above.
Personally I prefer to use the member var instead of the property because it
removes 1 step but in some cases there is validation that needs to be done
or other so I might need to use the property. Or in some cases a property
does not have a member var.

Interested to know other peoples thoughts.
Cheers
JB

[Andreas Håkansson]

John,

I would recommned using the property to gain access to the member
variable, especially since it is a read/write property. If the logic should
change regarding how the float returned by the b property is changed then
you will only have to modify your code in one place. And if you add other
logic (perhaps validate the range of m_b) or add security checks then you
will resuse that code.

HTH,

//Andreas

"John Baro" <jo***@NOSPAMme sware.com.au> skrev i meddelandet
news:DI******** ***********@new s-server.bigpond. net.au...

I have a class as:

public class a :
{
private float m_b;

public float b
{
get
{
return m_b;
}
set
{
m_b = value;
}

public float compute()
{
//*************** *************** *************** ********
//This method
return m_b * 369871;
//*************** *************** *************** ********
//Or this method
return b * 369871;
//*************** *************** *************** ********
}
}

What are peoples thoughts on the above.
Personally I prefer to use the member var instead of the property because it removes 1 step but in some cases there is validation that needs to be done
or other so I might need to use the property. Or in some cases a property
does not have a member var.

Interested to know other peoples thoughts.
Cheers
JB

[Jon Skeet [C# MVP]]

John Baro <jo***@NOSPAMme sware.com.au> wrote:

<snip>

What are peoples thoughts on the above.
Personally I prefer to use the member var instead of the property because it
removes 1 step but in some cases there is validation that needs to be done
or other so I might need to use the property. Or in some cases a property
does not have a member var.

I would recommend *always* using a property. Benefits of properties:

o The interface can remain consistent if the implementation changes
(e.g. to get the data from elsewhere, or compute it, or store it
in multiple variables)

o You can have a property which is read-only to the outside world,
but can be altered within your code (eg ArrayList.Count )

o From Whidbey onwards (and I don't know why it wasn't in to start
with) you will be able to have a property with different access
modifiers for set and get (at which point I'd recommend *only*
accessing the underlying variable from the property)

o You can easily add tracing or breakpoints to see when a value is used

o You can do validation etc

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

[Daniel O'Connell [C# MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

John Baro <jo***@NOSPAMme sware.com.au> wrote:

<snip>

What are peoples thoughts on the above.
Personally I prefer to use the member var instead of the property because
it
removes 1 step but in some cases there is validation that needs to be
done
or other so I might need to use the property. Or in some cases a property
does not have a member var.
I would recommend *always* using a property. Benefits of properties:

I would recommend it *almost* always(say 98-99%+ of the time). There are a
few situations where the property code really is a hassle. The most obvious
is marshalled structures, but other internal situations may permit using a
field for the sake of clarity.

Clarity is the point here. If the class doesn't need to consider versioning
and the class and developer would benifit from a clear, non cluttered view
of members, then simple properties aren't worth it. If there are a large
number of members and the class is little more than a datastore, then simple
properties are also probably not worth it.

While I may not go as far as Gunnerson does in his blog[1], I do think there
are cases where not bothering with the property outside of versioning
boundries is an acceptable approach. I would say that simple properties
should be used on all public, protected, and internal data members on public
and internal classes and on public structures, with the exception of nested
classes\structu res and other internal classes\structu res which are tightly
bound to a specific class. I would probably argue for public fields when you
are working with structures that exist for the purposes of 1) PInvoke or COM
Interop, or 2) Simple remoting\messag e passing. Such structures, IIMHO,
should have no behaviour and properties are a waste of time. They are
messages or interop middlemen and should be as simple as possible. I am
obviously not speaking about complex properties here(like using properties
to provide a simple interface to a bitfield or do validation, what have
you), I just mean simple get\set properties which do nothing but mask a
variable in a place where you'll likely never need validation or you can't
do validation and the code will be compiled with all the code that can
access it at all times.

With the coming of InternalsAccess ableToAttribute (Or whatever they are
calling it), internals potentially become versioning boundaries as well, so
use of properties on internal classes that may be used is a must.

This would be entirely moot if the language designers had considered the
prevalence of simple get\set properties and had provided property
declaration syntax as or nearly as simple as a field declaration or even if
the designers had chosen to completely eliminate fields(Perhaps that would
have been the right choice itself).

1. http://blogs.msdn.com/ericgu/archive.../12/52836.aspx

o The interface can remain consistent if the implementation changes
(e.g. to get the data from elsewhere, or compute it, or store it
in multiple variables)

o You can have a property which is read-only to the outside world,
but can be altered within your code (eg ArrayList.Count )

o From Whidbey onwards (and I don't know why it wasn't in to start
with) you will be able to have a property with different access
modifiers for set and get (at which point I'd recommend *only*
accessing the underlying variable from the property)

o You can easily add tracing or breakpoints to see when a value is used

o You can do validation etc

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