OOP Question

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!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:OGxb$7XMGHA.2712@.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!
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:eg4v5GYMGHA.1832@.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:OGxb$7XMGHA.2712@.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 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:OGxb$7XMGHA.2712@.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!
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:OGxb$7XMGHA.2712@.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:

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" <sloan@.ipass.net> wrote in message
news:%23CD04JYMGHA.964@.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:OGxb$7XMGHA.2712@.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" <elliotrodriguezatgeemaildotcom> wrote in message
news:OGxb$7XMGHA.2712@.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
lol...blame my parents, no me :)

Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/

"Vagabond Software" <vagabondsw-X-@.-X-gmail.com> wrote in message
news:eufRVfYMGHA.420@.tk2msftngp13.phx.gbl...
> "Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
> news:OGxb$7XMGHA.2712@.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