Reason for Accessor Methods

[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?

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

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.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Tenacious" <CT*******@yaho o.com> wrote in message
news:11******** **************@ g47g2000cwa.goo glegroups.com.. .

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?

[Bruce Wood]

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:

ProductCollecti on products = supplier.Produc ts;

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:

ProductCollecti on products = supplier.GetPro ducts();

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

supplier.Produc ts

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
OutOfMemoryExce ption. 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.

[Bruce Wood]

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.GetSom ething();

rather than this:

Thing someThing = myObject.Someth ing;

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.

[David Farr]

No confusion.

The question was generic, not database related. IMHO
:-)

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

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.GetSom ething();

rather than this:

Thing someThing = myObject.Someth ing;

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.

[Rick Lones]

Bruce Wood wrote:

I think that you're confusing properties with fields.
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.

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-

[David Farr]

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? :-)
Rick wrote:

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-

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

Dave

[Richard Grimes]

Tenacious wrote:

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?

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
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm