ReadOnly Properties - Arguements For/Against

[Rob Meade]

Hi all,

Ok - I guess this one will eventually still end up as a "personal choice"
kinda answer, but I thought I'd run it passed the wealth of knowledge and
experience that's in this group.

Typically when I'm writing my classes I'll have a series of properties which
I set to be read only, I'll then, if I need to write some methods for
setting the values of the class level variables exposed in the readonly
properties.

I appreciate I could remove the word "ReadOnly" and use the "Set" method of
the property but I've always felt that it would be better to have something
explicit for setting the values so that another developer in our team would
be fully aware when they are setting these values...

For example

' class variable
Private _name As String

' properties
Public ReadOnly Property Name() As String
Get
Return _name
End Get
End Property

' methods
Public Sub SetName(ByVal value As String)

' set variable
_name = value

End Sub


Obviously in the above example I could just as easily use the property to
set the value instead of writing a separate method as its only doing very
simple things and with no big consequences.

I would be interested to know from others whether or not you do anything
similar or just use the properties to both get and set values.

Typically my classes themselves set the values, but every now and then they
will be the need for something else to set them, hence the sub being public
etc...

Any info appreciated.

Regards

Rob

 

[Karl Seguin]

I disagree with your approach simply because it doesn't jive with
conventional tactics. I can't say why it's convential or not, it simply is
and therefore you've increased the learning curve of your programs and
provided no advantages for doing so. I always learnt that methods were
about behaviour and properties about state, ur code seems to mix this up
unecessarily.

In general, the only time I use properties are for identity keys (shouldn't
be able to set a UserId) and collections (because that's plain'ol good
design).

Take a look at for more insight (there's plenty of comments I haven't read,
so you might find arguments supporting your point)
http://blogs.msdn.com/brada/archive/2003/11/13/50672.aspx

Karl

 

[Patrice]

What makes you think that :

MyObject.Name="SomeValue"

is not explicit ?

Actually it's perhaps even more explicit as you see the assignment operator
(while your replacement is just a method call and you guess from the name
that it actually updates the Name property).

 

[Chris Priede]

Hi,

If the item to get or set behaves like a variable from the perspective of
someone thinking of your class as a black box -- what you set it to is the
same thing you'd expect to get back, although there could be some internal
logic involved -- then it is perfectly suited to be a property with get/set
accessors.

If the item is being set by deriving it from something else, or some other
appreciable action (from the same black box perspective) is being performed
in connection with setting it, then your suggested approach is appropriate.

 

[Teemu Keiski]

Hi,

"> I would be interested to know from others whether or not you do anything

similar or just use the properties to both get and set values.

I usually stick to properties because that way all get/set related code is
in one place. Just personal preference.

Typically my classes themselves set the values, but every now and then
they will be the need for something else to set them, hence the sub being
public etc...

Yes, that's also a reason to use separate method if the access level of the
entire property cannot be public etc. In .NET v2.0 you can have different
access levels for get/set in properties so that solves that part of the
issue.

 

[Rob Meade]

Thanks all for your replies, deffo some food for thought...

Cheers

Rob