Reason for Accessor Methods

  • Thread starter Thread starter Tenacious
  • Start date Start date
T

Tenacious

I have been programming using C# for over a year now and I still wonder
what is the importance of using accessor methods when the property is
read-write. It seems easier to just make it a public property of the
class, but I have read in more than one book that this is a bad
practice. The books did not mention the reason why this is a bad
practice. Can anybody give me some insight on this?
 
Tenacious,

The general guideline I have seen in the class design recommendations
from MS say that you should use Get and Set methods when the change is a
significant operation, not just another property on an object.

Before C# 2.0, you had to use Get and Set methods if you wanted the
access levels to be different (private/public, for example).

In C# 2.0 now, you can have different accessor levels on the get and the
set, which eliminates that particular need for Get and Set accessor methods.

I would agree with the original design guideline though, that if the
operation is doing something significant, then it should be its own method.
 
The idea, I believe, is that callers perceive properties as "cheap" to
call, and therefore have no qualms about calling them inside loops,
etc.

A method call, on the other hand, registers with callers as something
potentially expensive.

If doing this:

ProductCollection products = supplier.Products;

causes a massive query to the database plus a whole whack of
DataRow-to-object conversions and a final sort to occur, then it should
probably be written like this:

ProductCollection products = supplier.GetProducts();

as a sort of visual warning that this could take a while.

supplier.Products

looks too innocuous to draw much attention.

The other guideline that I recall is that in general properties
shouldn't throw exceptions. If your property is doing something complex
enough that it can generate exceptions then it should probably be a
method, for the same reason stated above: caller perception.

That said, these are general guidelines. Many properties can throw an
OutOfMemoryException. Many others do considerable work. It's all a
question of knowing whether your callers are sophisticated enough to
know that even a simple property reference has the potential to chew up
cycles and throw exceptions. MS is betting that most don't.
 
There is also the question of re-use:

If you expose your properties directly there is a risk of breaking something
if you decide at a later date to change the internals of the class.
e.g. you may set or unset X directly, but later you may wish to keep track
internally of how many times X is set or unset, which impacts another
property.

Also as Bruce hinted at, you may wish to do bounds checking on the value,
rather than just blindly changing it.

Dave
 
I think that you're confusing properties with fields. The OP was asking
for reasons why you would prefer to write this:

Thing someThing = myObject.GetSomething();

rather than this:

Thing someThing = myObject.Something;

where Something is a property with a getter (and perhaps a setter).

Certainly, it's preferable to expose properties rather than expose
fields directly. The question was, why would you prefer to write a Get
method rather than use a property with a getter.
 
Bruce said:
I think that you're confusing properties with fields.
Click to expand...

So do I.
Certainly, it's preferable to expose properties rather than expose
fields directly. The question was, why would you prefer to write a Get
method rather than use a property with a getter.
Click to expand...

He did not mention "writing a Get method". Given:

public class c
{
private string _s;

public string s
{
get {return _s;}
}
}

I think the OP's actual question is "What is preferable about the indirection
here? Why not just have the field be "public string s"? I don't believe the
question involved methods (yet a third way to do it, sort of - "get" IS a method
as far as I am concerned) at all. I think it's more like "What's so great about
data hiding that everyone speaks of it as being 'certainly preferable' when most
of the examples given are as trivial as the one above?" A good tenacious
question, IMO.

-rick-
 
I stand corrected. I was in this instance, I don't have a formal MS
background, so my terminology doesn't always tally.

Perhaps Tenacious could restate the question. Do you mean "what is the
importance of using accessor methods when the field is
read-write" as I understood it in my own way? :-)

I think it's more like "What's so great about data hiding that everyone
speaks of it as being 'certainly preferable' when most of the examples
given are as trivial as the one above?" A good tenacious question, IMO.

-rick-
Click to expand...

True for a trivial example, but only if you can guarantee that it will
remain so.

Dave
 
Tenacious said:
I have been programming using C# for over a year now and I still
wonder what is the importance of using accessor methods when the
property is read-write. It seems easier to just make it a public
property of the class, but I have read in more than one book that
this is a bad practice. The books did not mention the reason why this
is a bad practice. Can anybody give me some insight on this?
Click to expand...

I think that properties should be used sparingly. The example I give is
the Control properties Height, Width, Left, Top. For example:

Form f = new Form();
f.Visible = true;
// do some stuff with default size and position, then change size and
position
f.Width = 200;
f.Height = 200;
f.Left = 100;
f.Top = 100;

Each of these properties is implemented with a call to SetBounds. It is
far better to write:

f.SetBounds(100, 100, 200, 200);

SetBounds will raise events, and your intention is to size and position
the form, hence you want just one event to say the form has moved.

I think it was wrong of the Forms team to have provided these
properties, SetBounds (this one and the overload) do exactly what you
want them to; the properties help you to write incorrect code.

Richard
 
Back
Top