setting private fields in a constructor

  • Thread starter Thread starter Michael Roper
  • Start date Start date
M

Michael Roper

If a class uses public properties to expose private fields, and has a
constructor to initialize those fields, should the constructor set them
directly or use the set accessors? Or does it matter?

Michael Roper
 
I don't think there's a general answer to this one.

If the set accessor simply sets the field and nothing more, then there's
not much odds. One might worry that the set accessor is a bit slower,
but I think that will be optimised away in most cases. However, even if
the set accessor does nothing special, there is always the issue that it
might do something in future.

If the set accessor does do something special, then its a question of
whether you want to do that special thing. As class desginer you know
what needs to be done and you can make the decisions.

For example, suppose you have a set accessor that ensures an int is in
the range 0-10, and throws an exception if not. If you call it with a
hard-coded 0 in the constructor, then you're wasting time going through
the set accessor. However, if the restriction were to change, then 0
might become invalid and you'd want to catch that.

If the set accessor were to, say, count the number of times that the
field was changed, then you certainly wouldn't want to increment that
count from the constructor, because thats initialisation, not change.

Another issue to consider is if the property is virtual. If so, then you
probably should call the set accessor to pick up any derived
functionality, but again it may depend on the context. Also, calling
virtual methods from a constructor is always dubious - less so in C#
than it was in C++, but still not great.

Regards,

Jasper Kent
 
Just to put in my two-cents. I almost always use the property getter /
setter within my own classes - including the constructor. If I'm doing any
sort of bounds checking / error checking then I surely want to make sure I
continue to use that, inside or outside of my class. Purely cosmetic, but I
generally think the code is easier to read - at least for me:

public MyClass()
{
Width = 10;
}

vs.

public MyClass()
{
_width = 10; // or
this.width = 10;
}

Plus, I think it helps encapsulation even more. Say you move _width and
_height into a _size or _rectangle structure, then you just change your
properties and the rest of your code still works.

There are, of course, some places where I don't use the property (for
example, maybe I need to reset a field to null within my class, but I don't
allow other classes to do that). But most of the time, I prefer to use the
property.
 
The danger comes when Width is virtual because it may attempt to do things
with objects that are not yet initalized.
 
Michael said:
I almost always use the property getter/setter
within my own classes - including the constructor.
Click to expand...

I like this approach, and the encapsulation point you made later also
appeals. However, I'm having trouble getting the behavior I'd like (or
expect) from properties in a couple of regards.

One, I seem unable to assign different access modifiers for the set and get
of a property. For example, I might like to have a private setter
(something I'd do on behalf of the class client in the constructor, say) and
a public getter.

Two, I can't stick the private field associated with a property in the
property itself (thereby enforcing property-only access to the field even
within the class, and enhancing encapsulation).

I'm sure there's a good reason I can't do these things, but it seems like
they'd be nice to have.

Michael Roper
 
Michael Roper said:
I like this approach, and the encapsulation point you made later also
appeals. However, I'm having trouble getting the behavior I'd like (or
expect) from properties in a couple of regards.

One, I seem unable to assign different access modifiers for the set and get
of a property.
Click to expand...

Indeed. That's being fixed in the next version of C#.
For example, I might like to have a private setter
(something I'd do on behalf of the class client in the constructor, say) and
a public getter.
Absolutely.

Two, I can't stick the private field associated with a property in the
property itself (thereby enforcing property-only access to the field even
within the class, and enhancing encapsulation).

I'm sure there's a good reason I can't do these things, but it seems like
they'd be nice to have.
Click to expand...

I don't think there *is* a good reason, I'm afraid - I've put in the
latter as a feature request, but I don't know whether or not it'll be
heeded. For the benefit of serialization etc, it would probably be
worth having an extra attribute which allowed methods to access
property-scoped variables, but that (and some naming restrictions) are
the only wrinkles I can see.
 
Thanks for your response Jon. I find the traffic in this group rather
overwhelming--I don't know how you do it!

Jon said:
Indeed. That's being fixed in the next version of C#.
Click to expand...

That'll help. Is there a definitive "next version of C#" doc/timeline to be
had?

Michael Roper
 
Willy Denoyette said:
Jon, Are you sure about this? Any references?

Willy.
Click to expand...
Jon, Did some research myself, and you were right, this feature is planned for the next release of C# and VB.NET.

Willy.
 
Back
Top