OOP Question

[Elliot Rodriguez]

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and access
it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access the
local variable as opposed to getting the property value using Me.BarString?
In debugging it seems the compiler has to retrieve the value anyway, and
accessing the local variable is more "direct", so I assume does not have the
same performance implications that using Me.BarString does.

Thanks!

[Karl Seguin [MVP]]

Accessing private fields within the class itself isn't too bad. Afterall,
that's the definition of a private field ;)

it does break the encapsulation provided by the property however. Say for
example that your property did a little more like:

get
if (m_strBar is nothig) then
return m_anotherFireld
end if
return m_strBar
end get
suddenly, by accessing m_strBar you are missing out on the functinality
provided by the property...sometimes this'll be what you want, sometimes it
won't.

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl...

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and access
it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access
the local variable as opposed to getting the property value using
Me.BarString? In debugging it seems the compiler has to retrieve the value
anyway, and accessing the local variable is more "direct", so I assume
does not have the same performance implications that using Me.BarString
does.

Thanks!

[Elliot Rodriguez]

Thanks for giving me a good answer, and another angle to look at it, Karl.

"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:eg**************@TK2MSFTNGP11.phx.gbl...

Accessing private fields within the class itself isn't too bad. Afterall,
that's the definition of a private field ;)

it does break the encapsulation provided by the property however. Say for
example that your property did a little more like:

get
if (m_strBar is nothig) then
return m_anotherFireld
end if
return m_strBar
end get
suddenly, by accessing m_strBar you are missing out on the functinality
provided by the property...sometimes this'll be what you want, sometimes
it won't.

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl...

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and
access it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access
the local variable as opposed to getting the property value using
Me.BarString? In debugging it seems the compiler has to retrieve the
value anyway, and accessing the local variable is more "direct", so I
assume does not have the same performance implications that using
Me.BarString does.

Thanks!

[sloan]

I usually refer to it as the member variable.

public void DoSomething()
{
this.m_bar = "I am a Bar";
}

...

While I see alot of c#'ers use "this", not many vb'ers use Me. I happen to
use Me.

Like this

public sub DoSomething

Me.m_bar = "I am a VB Bar"

end Sub
You'll also notice there is no "str". That ~was VB6. go and google "Brad
Abrams" "Naming conventions" to find more.

My main reasoning is maintenance. When I use

this.m_bar;

I know EXACTLY what I'm talking about.

Sometimes... in the Property, it might be a derived property.
Public int Age
{ get { return DateTime.Now.Substract(m_dateOfBirth).ToYear(); }}

something like that (that won't compile, Im just showing an FYI. I take
todays date, substract the date of birth, and get the Year of the
difference.
I can't "prove" that using this.MyProperty is wrong... it just feels very
wrong to me.

"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl...

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and access
it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access the local variable as opposed to getting the property value using Me.BarString? In debugging it seems the compiler has to retrieve the value anyway, and
accessing the local variable is more "direct", so I assume does not have the same performance implications that using Me.BarString does.

Thanks!

[Kevin Spencer]

Hi Elliott,

My question is - is there any reason why I should, or should not, access
the local variable as opposed to getting the property value using
Me.BarString?
There are a number of reasons you would want to use a property. But it isn't
always necessary. One of the most obvious reasons is that the property
getter and setter are methods, which can do any additional processing you
want when getting or setting the value. Another is that a property getter
and setter do not always work with field values. Sometimes they work with
calculated values, or multiple other fields, properties, and/or methods.
Interacting with some technologies can require a property rather than a
field. Those are the most common ones I can think of off the top of my head.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl... Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and access
it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access
the local variable as opposed to getting the property value using
Me.BarString? In debugging it seems the compiler has to retrieve the value
anyway, and accessing the local variable is more "direct", so I assume
does not have the same performance implications that using Me.BarString
does.

Thanks!

[Elliot Rodriguez]

Sloan:

Thanks for your perspective. I know that the naming conventions I used in my
example are deprecated, but for me its a matter of preference, and its for a
personal project so I stick with it. Not to get too tangential here, but I
find that the changes in conventions have been mostly a matter of style and
in some cases improved readability, although I dont see how it helps or
hurts, personally.

Unless the compiler has issues with it that I simply dont know about...
"sloan" <sl***@ipass.net> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

I usually refer to it as the member variable.

public void DoSomething()
{
this.m_bar = "I am a Bar";
}

..

While I see alot of c#'ers use "this", not many vb'ers use Me. I happen
to
use Me.

Like this

public sub DoSomething

Me.m_bar = "I am a VB Bar"

end Sub
You'll also notice there is no "str". That ~was VB6. go and google "Brad
Abrams" "Naming conventions" to find more.

My main reasoning is maintenance. When I use

this.m_bar;

I know EXACTLY what I'm talking about.

Sometimes... in the Property, it might be a derived property.
Public int Age
{ get { return DateTime.Now.Substract(m_dateOfBirth).ToYear(); }}

something like that (that won't compile, Im just showing an FYI. I take
todays date, substract the date of birth, and get the Year of the
difference.
I can't "prove" that using this.MyProperty is wrong... it just feels very
wrong to me.

"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl...

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and
access
it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access

the

local variable as opposed to getting the property value using

Me.BarString?

In debugging it seems the compiler has to retrieve the value anyway, and
accessing the local variable is more "direct", so I assume does not have

the

same performance implications that using Me.BarString does.

Thanks!

[Vagabond Software]

"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl...

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and access
it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access
the local variable as opposed to getting the property value using
Me.BarString? In debugging it seems the compiler has to retrieve the value
anyway, and accessing the local variable is more "direct", so I assume
does not have the same performance implications that using Me.BarString
does.

Thanks!

I think Karl has the right of it, though he does spell his name incorrectly.

I always read from the property rather than the private field for the reason
he points out. Say I am writing a data object and my database does not
permit null values or I simply don't want null values written to the
database.

Private _firstName As String

Private Property FirstName As String
Get
If _firstName Is Nothing
_firstName = String.Empty
End If

Return _firstName
End Get
End Property

Obviously, I have omitted the Set block. Unlike value types (Integer,
Boolean, etc) most reference types are not initialized upon declaration.
They remain Nothing until assigned. For Example:

Dim value1 As Integer
Dim value2 As String

At this point in the code, Value1 is equal to 0 (zero) and value2 is
Nothing. So, by using our properties rather than the private field when we
send our data object to our data class, we avoid null values in our database
automatically, even if we did not populate the string fields.

carl

[Karl Seguin [MVP]]

lol...blame my parents, no me :)

Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Vagabond Software" <[e-mail]> wrote in message
news:eu*************@tk2msftngp13.phx.gbl...

"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:OG**************@TK2MSFTNGP10.phx.gbl...

Given the following:

Public Class Foo
Private m_strBar as string

Public Property BarString as String
Get
BarString = m_strBar
End Get

Set(ByVal value as string)
m_strBar = value
End Set
End Property

Public Sub DoSomething

End Sub
End Class

I need to access information related to the BarString property, and
access it within the DoSomething sub.

My question is - is there any reason why I should, or should not, access
the local variable as opposed to getting the property value using
Me.BarString? In debugging it seems the compiler has to retrieve the
value anyway, and accessing the local variable is more "direct", so I
assume does not have the same performance implications that using
Me.BarString does.

Thanks!

I think Karl has the right of it, though he does spell his name
incorrectly.

I always read from the property rather than the private field for the
reason he points out. Say I am writing a data object and my database does
not permit null values or I simply don't want null values written to the
database.

Private _firstName As String

Private Property FirstName As String
Get
If _firstName Is Nothing
_firstName = String.Empty
End If

Return _firstName
End Get
End Property

Obviously, I have omitted the Set block. Unlike value types (Integer,
Boolean, etc) most reference types are not initialized upon declaration.
They remain Nothing until assigned. For Example:

Dim value1 As Integer
Dim value2 As String

At this point in the code, Value1 is equal to 0 (zero) and value2 is
Nothing. So, by using our properties rather than the private field when
we send our data object to our data class, we avoid null values in our
database automatically, even if we did not populate the string fields.

carl