Accessing class member variables - properties or variables?

[dwok]

I have been wondering this for a while now. Suppose I have a class
that contains some private member variables. How should I access the
variables throughout the class? Should I use properties that expose the
variables or is it OK to just access the variables directly? Keep in
mind that I am talking about accessing the variables from within the
class that they are defined. Thanks!

 

[klynn47]

Regardless of what level of access you give an instance variable, it
can be accessed in any instance method in the class definition.

 

[Ken Tucker [MVP]]

Hi,

I would access the variables directly from within the class. Use
properties for accessing them from outside the class.

Ken
-----------------
I have been wondering this for a while now. Suppose I have a class
that contains some private member variables. How should I access the
variables throughout the class? Should I use properties that expose the
variables or is it OK to just access the variables directly? Keep in
mind that I am talking about accessing the variables from within the
class that they are defined. Thanks!

 

[Guest]

Only expose your private members if you wish them to be publicly acessible,
that sounded horrible... I only create properties to be externally consumed
by another class, say I have a class that gets loaded from the database and I
have a property that accesses the data:

Public Overridable ReadOnly Property SomeData() As String
Get
Return m_SomeData
End Get
End Property

I'm going to poulate this properties value using the private member
m_SomeData, that way I don't interfere with anyone else's implementation
should they descide to override this property.

 

[Herfried K. Wagner [MVP]]

I have been wondering this for a while now. Suppose I have a class
that contains some private member variables. How should I access the
variables throughout the class? Should I use properties that expose the
variables or is it OK to just access the variables directly? Keep in
mind that I am talking about accessing the variables from within the
class that they are defined.

I think this is the way most developers do it.

Nevertheless, I use 'Static' [VB.NET] variables inside methods whenever it
makes sense to use them, and I never access member variables which are
holding property values directly, except in the property's 'Get' or 'Set'
block.

 

[Hal Rosser]

I have been wondering this for a while now. Suppose I have a class
that contains some private member variables. How should I access the
variables throughout the class? Should I use properties that expose the
variables or is it OK to just access the variables directly? Keep in
mind that I am talking about accessing the variables from within the
class that they are defined. Thanks!

I assume by 'member' variables, you mean 'instance' variables (which can be
thought of as 'properties' of an instance of the class). <<<as a general
rule>>> Normally, instance variables are declared private and normally,
the 'get' and 'set' methods to access them are declared public. individual
mileage may vary.
'Static' variables (and constants) belong to the class without regard to any
instance (VB.NEt's Color.Blue for example).

 

[Bruce Wood]

It all depends upon the situation.

For example, I have a class in which setting a property through the
"set" method causes the class to fire an event saying that the value
changed. Sometimes, from within the class I want to set it in this way;
if I forget, any subscribers won't know that the value changed. Other
times, I definitely want to just set the value, without firing an
event.

What I'm driving at here is that properties often do more than just set
the value of a private member: they do additional processing. This is
particularly common in WinForms applications in which objects must
notify the UI that something has changed and needs to be redisplayed.

In those cases in which a property does nothing more than set the
member variable, most developers just set the member variable directly.

 

[Herfried K. Wagner [MVP]]

Hal,

'Static' variables (and constants) belong to the class without regard to
any
instance (VB.NEt's Color.Blue for example).

In VB.NET, variables marked as 'Static' belong to the method they are
decalared in:

\\\
Private Sub Foo()
Static x As Integer
...
End Sub
///

Properties like 'Color.Blue' are shared properties ('Shared' modifier).

 

[Hal Rosser]

Hal,



In VB.NET, variables marked as 'Static' belong to the method they are
decalared in:

\\\
Private Sub Foo()
Static x As Integer
...
End Sub
///

Properties like 'Color.Blue' are shared properties ('Shared' modifier).

Oh YEAH! you're right! I should not have inserted a reference from VB, since
I was answering the OP in terms of Java. - In VB, 'static' refers to a
variable that keeps its value from call to call - and is really not
applicable in the context of this thread. I was answering the OP in terms of
Java (but foolishly inserted a VB reference - ie: Color.Blue )
In Java - the Color.Blue reference analogy would be referring to a variable
named "Blue" which was declared "static" in the class named "Color". Hence
the ability to reference "Blue" without creating an instance of the "Color"
class.