Properties vs fields

  • Thread starter Thread starter keithv
  • Start date Start date
K

keithv

I'm looking at a bunch of code which has lots of class
fields converted into properties with just the simplest code:

private int empID;
public int empID {
get { return empID; }
set { empID = value; }
}

My question is, isn't this useless and inefficient?

I can't see any benefit to this form of encapsulation over
just making the field public. Later, if you do want to add
some checking or whatever, you can just change the class
to make the field private and add the accessor/mutator
code w/o changing the code which uses the class.

The downside to using properties is efficiency. Every access
to this property is now a function call. It's also annoying
while single-stepping in the debugger, especially code like
"foo(joe.empID);" because you're forced to step into the
accessor code.

Is there some benefit that I'm missing, perhaps dealing
with inter-language issues?

Keith
 
I think you said what the benefit is. Is that you can change the property's
code any time, to add extra checking, etc.

Also, making a field public, means users can read and write to it. Where as
with a property, you can make it read only or write only - which can be very
important.

Yes, a property is only syntactic sugar for get/set methods. So the reasons
for using a property, are the same as those for having written the get/set
methods.

Additionally, using properties follows the .NET standard, properties will
have a specific icon pop up in intellisense. Your documentation will look
like the .NET documentation, etc.
 
In addition to what Marina said, you actually change the type definition
when you make the change from a field to a property. This can have very
serious side effects, depending on what is using your components. Whatever
is using your code will have to be recompiled. It's better to just use
properties off the bat, and try to minimize huge changes like that in the
future.

Hope this helps.
 
Look closely at your code; the usual practice is to capatilize the first
letter of the public variable, while the first letter of the private version
is lower case.

As thus:

private int empID;
public int EmpID { get set etc.}

you can put whatever validation code you want in the get/set accessors.

J
 
ot provides a layer of indirection so I could later change it to

private double empID;
public int empID {
get { return (int)empID; }
set { empID = value; }
}

without breaking clients. I can also add validation in

private int empID;
public int empID {
get { return empID; }
set
{
if( empID == 0 )
throw new Exception(" emdID cannot be zero);
empID = value;
}
}

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

I'm looking at a bunch of code which has lots of class
fields converted into properties with just the simplest code:

private int empID;
public int empID {
get { return empID; }
set { empID = value; }
}

My question is, isn't this useless and inefficient?

I can't see any benefit to this form of encapsulation over
just making the field public. Later, if you do want to add
some checking or whatever, you can just change the class
to make the field private and add the accessor/mutator
code w/o changing the code which uses the class.

The downside to using properties is efficiency. Every access
to this property is now a function call. It's also annoying
while single-stepping in the debugger, especially code like
"foo(joe.empID);" because you're forced to step into the
accessor code.

Is there some benefit that I'm missing, perhaps dealing
with inter-language issues?

Keith
 
about the efficiency. the JIT will most likely inline the get/set methods
when they are one liner as such (if they are not virtual), so it will be just
as efficient as if you were calling the fields directly in simple cases. you
will not incur the extra stack frame for the method. no penalty.
 
And I guess I should add here that since C# is case sensitive, the two
variables empID and EmpID are separate and distinct. This is the mechanism
that provices encapsulation to the private variable.

private int empID;
public int EmpID
{
get
{
return empID;
}
set
{
// validation code;
empID = value;
}
}

Or, to make empID ReadOnly, just omit the set accessor.

J
 
And as for the single-stepping, you are never forced to "step into". Why not
use "step over" unless you think you have a reason to go into a function?
(If the something you are watching has an unexpected value after you
"step over" something, you can always go back and step in next time.) I
have found stepping over as my default behavior to be a big time saver when
stepping through code even without using properties(get/sets).

-Rachel
 
keithv said:
It's also annoying
while single-stepping in the debugger, especially code like
"foo(joe.empID);" because you're forced to step into the
accessor code.
Click to expand...

You can use the System.Diagnostics.DebuggerStepThroughAttribute to prevent
that. For trivial gets and sets I usually do this:

public IUIShell UIShell
{
[System.Diagnostics.DebuggerStepThrough]
get{ return this.uiShell; }
}

This is handled by the debugger, though, so if you have a debugger that
doesn't respect the attribute, it doesn't help. But then again, it's not
like people are using a wide range of different debuggers...

--
Arild

AnkhSVN - Subverting Visual Studio .NET: http://ankhsvn.tigris.org
Blog: http://ankhsvn.com/blog
IRC: irc://irc.freenode.net/ankhsvn

"Gentlemen, you can't fight in here! This is the war room!"
 
And as for the single-stepping, you are never forced to
"step into". Why not use "step over"
Click to expand...

The problem arises when you want to step into a function
that takes a property as a parameter, e.g. foo(joe.EmpID);
You can't step into foo() w/o also stepping into the get.

Keith
 
In addition to what Marina said, you actually change the
type definition when you make the change from a field to
a property. This can have very serious side effects...
Click to expand...

Can you explain further? Yes there'll have to be a recompile
but that happens daily and I wouldn't consider that a "very
serious side effect".

Keith
 
keithv said:
Can you explain further? Yes there'll have to be a recompile
but that happens daily and I wouldn't consider that a "very
serious side effect".
Click to expand...

1) Recompilation alone won't catch everything - you can pass a variable
by ref, but not a property, for example.

2) Recompilation may happen daily during development, but if anyone
else is developing components to work with your type, they may have
released a binary already...
 
Back
Top