Get set... what do i use .

[ucasesoftware]

If i have this property

Dim m_name as string

Property name() as string
Get
return m_name
end Get
Set (byval Value as string)
m_name = Value
End set
End property


In my code i have to use m_name or name ?

 

[Terry Olsen]

You would use m_name inside the class that has this property. When setting
or getting the name property from outside the class, you would use name.

 

[ucasesoftware]

ok thx

One other question :

in class method... can i use sql connexion like that ? or... it's not
good ?

Public Class monAgenda


Dim m_agendaGuid As Guid
Property agendaGuid() As Guid
Get
Return m_agendaGuid
End Get
Set(ByVal Value As Guid)
m_agendaGuid = Value
End Set
End Property

Dim m_entrepriseGuid As Guid
Property entrepriseGuid() As Guid
Get
Return m_entrepriseGuid
End Get
Set(ByVal Value As Guid)
m_entrepriseGuid = Value
End Set
End Property


Dim m_salarieGuid As Guid
Property salarieGuid() As Guid
Get
Return m_salarieGuid
End Get
Set(ByVal Value As Guid)
m_salarieGuid = Value
End Set
End Property


Dim m_agendaNom As String
Property agendaNom() As String
Get
Return m_agendaNom
End Get
Set(ByVal Value As String)
m_agendaNom = Value
End Set
End Property

Dim m_firstHour As String
Property firstHour() As String
Get
Return m_firstHour
End Get
Set(ByVal Value As String)
m_firstHour = Value
End Set
End Property

Dim m_workHourBegin As String
Property workHourBegin() As String
Get
Return m_workHourBegin
End Get
Set(ByVal Value As String)
m_workHourBegin = Value
End Set
End Property

Dim m_workHourEnd As String
Property workHourEnd() As String
Get
Return m_workHourEnd
End Get
Set(ByVal Value As String)
m_workHourEnd = Value
End Set
End Property

Dim m_hourResolution As String
Property hourResolution() As String
Get
Return m_hourResolution
End Get
Set(ByVal Value As String)
m_hourResolution = Value
End Set
End Property


Dim m_isRdv As Boolean
Property isRdv() As Boolean
Get
Return m_isRdv
End Get
Set(ByVal Value As Boolean)
m_isRdv = Value
End Set
End Property

Dim m_template As String
Property template() As String
Get
Return m_template
End Get
Set(ByVal Value As String)
m_template = Value
End Set
End Property


Public Function agendaOwner(ByVal salarieGuid As Guid) As String
Try
Dim myConnexion As New SqlConnection
ouvreConnexion(myConnexion)
Dim cmd As SqlCommand
cmd = New SqlCommand("SELECT salarie.prenom + ' ' +
salarie.nom + ' (' + entreprise.raisonSociale + ')' AS nomComplet FROM
salarie INNER JOIN entreprise ON salarie.entrepriseGuid =
entreprise.entrepriseGuid where salarieGuid = '" & salarieGuid.ToString
& "'", myConnexion)
Return cmd.ExecuteScalar
Catch ex As Exception
monErreur(ex)
End Try
End Function



End Class

 

[Herfried K. Wagner [MVP]]

You would use m_name inside the class that has this property. When
setting or getting the name property from outside the class, you would use
name.

Personal preference. I prefer using the property over the private variable,
because this would add the benefit of validation, especially when assigning
a new value to the property.

 

[ucasesoftware]

and for my question about sql connexion ?

 

[m.posseth]

i do not concure with that ,,,,,

i use the property name inside the class with the me prefix ( although
without is also valid however, i am lazy so i use the intellisense
feature )
property`s might encapsulate validators / constrainst / business logic
that is why it is always good coding practice to use them instead of the
underlying variabels


And yes it is valid to use a sql connection like that in your class code

regards

Michel Posseth [MCP]

 

[Armin Zingler]

Dim m_agendaGuid As Guid
Property agendaGuid() As Guid
Get
Return m_agendaGuid
End Get
Set(ByVal Value As Guid)
m_agendaGuid = Value
End Set
End Property

I recommend not using property procedures in this case because they don't do
anything but get/set the value. Use a Public field instead (Public
agendaGuid As Guid).


Armin

 

[Micky]

If i have this property

Dim m_name as string

Property name() as string
Get
return m_name
end Get
Set (byval Value as string)
m_name = Value
End set
End property


In my code i have to use m_name or name ?

Since the example Get/Set accessors have no
validation, you don't need the property at all.
A public variable alone would suffice.

Public m_Name As String

You then access m_Name both inside and outside
of the class.

However, if validation is required, it's always
better to use a private variable with access to it
via the property (which includes the validation
code), both inside and outside of the class.

In other words, "keep your powder dry".

 

[Herfried K. Wagner [MVP]]

Since the example Get/Set accessors have no
validation, you don't need the property at all.
A public variable alone would suffice.

Public m_Name As String

You then access m_Name both inside and outside
of the class.

I have to disagree. Properties are the way to go when modeling an entity's
attributes. Additionally, changing the implementation of the property
(i.e., adding validation) would not break client code using the class,
whereas changing the public variable to a property will do.

 

[Micky]

I have to disagree. Properties are the way to go when modeling an entity's attributes. Additionally, changing the
implementation of the property (i.e., adding validation) would not break client code using the class, whereas changing
the public variable to a property will do.

You make a valid point, Herfried. I stand corrected.

 

[Phill. W]

I recommend not using property procedures in this case because
they don't do anything but get/set the value. Use a Public field
instead (Public agendaGuid As Guid).

I would /still/ argue for using properties, /even if/ all they do is get
or set the value. If you start your application using a field, then
change it to a property later on, you will *break* existing, deployed
code. Besides, you should always /validate/ property values as they
are set (unless they're Boolean's of course).

Regards,
Phill W.

 

[Armin Zingler]

I would /still/ argue for using properties, /even if/ all they do is
get or set the value. If you start your application using a field,
then change it to a property later on, you will *break* existing,
deployed code.

I design a member based on the current needs or the needs that are planned
for the future. If there's no need to make a property, I use a public field.
I won't make them *all* properties just because one *might* become a
property later. When will it be? Next year? In five years? Probably never?

In other words, I want to look at a component or it's source code at any
given point of time and it must make sense at the same point of time. If I
now look at the op's code, I'd call it bad design because the property
procedures are not necessary.

Later, if it has to be changed to a property, and if this breaks existing
code, well, that's how it is if we change the interface. Better than now
having unnecessary code.

I admit I might have a little more work later, but a) not even the
field's/property's usage changes, b) not very probable and c) better
than now having the work of writing a property instead of a field.

Luckily, the JIT-compiler can optimize these simple properties to inline
field access.

Besides, you should always /validate/ property
values as they are set (unless they're Boolean's of course).

If there is something to check, I do use a property. This was not the case
in the op's code.

Armin