Classes, Properties, and structures

[OpticTygre]

Alright, so I'm messing around with some code, and I brought up a good
question to myself.

If creating a class called "Person", and filling that class with variables,
properties like:

Public Class Person
Private mstrName As String
Private mdtBirthDate As Date

Public Property Name() As String
Get
Return mstrName
End Get
Set(ByVal Value As String)
mstrName = Value
End Set
End Property

etc......

What is the benefit of typing out all that code over defining a simple
structure such as:

Structure Person
Public Name As String
Public BirthDate As Date
End Structure



-J

 

[Larry Serflaten]

Alright, so I'm messing around with some code, and I brought up a good
question to myself.

If creating a class called "Person", and filling that class with variables,
properties like:

What is the benefit of typing out all that code over defining a simple
structure such as:

The typical answer is because you want to separate the interface from
the implementation such that you can make later adjustments to the
implementation, without affecting the interface.

If, for example, it was later decided that records would be rejected when
the Birthday was entered as being in the 1800's, you could add that as
a requirement in the properties's Let block. If you just had a field member
you could not add it without creating a new interface (and breaking old code
that used the old interface).

LFS

 

[David Browne]

The typical answer is because you want to separate the interface from
the implementation such that you can make later adjustments to the
implementation, without affecting the interface.

If, for example, it was later decided that records would be rejected when
the Birthday was entered as being in the 1800's, you could add that as
a requirement in the properties's Let block. If you just had a field
member
you could not add it without creating a new interface (and breaking old
code
that used the old interface).

But the OP has a point that those two classes "look" the same to client
code. One of the things I like best about Properties is that if you change
a public field to a property your client code will need to be recompiled,
but it won't need to change.

So you can code the simple Person struct and later add encapsulation with
properties.

David

 

[OpticTygre]

Interesting point. I suppose also, that since it is a class, there is also
the ability to add function, subroutines, events and such that apply
specifically to an object of type "Person" whereas you wouldn't be able to
do something like that with a simple structure. And what's wrong with being
born in the 1800's? It's possible! =) I plan on living forever, and so
far my plan is working perfectly. heheh.

-Jason

 

[Guest]

Using Class properties does allow you to process the user input to the class
and check that it's valid. Also, there are somethings that you can't do with
Structures that you can do with Classes. I'm sure there are many but here
are a couple:

if mystructure is nothing then 'generates a compile error since a
structure is a value type

ArrayLists of structures can't be bound to controls but arraylists of
classes can.

You can get some benefit of structures and classes by using fields in the
class instead of properties, i.e.,

Public Class person
public name string
public birthdate as string
end class

 

[David Browne]

Interesting point. I suppose also, that since it is a class, there is
also the ability to add function, subroutines, events and such that apply
specifically to an object of type "Person" whereas you wouldn't be able to
do something like that with a simple structure.

You can add methods, properties, etc to a structure. The distinction
between a Class and a Structure is that a class is created on the heap, and
a structure is a ValueType created on the stack.

A ValueType which contains only ValueType's for fields will be created
entirely on the stack and won't generate any garbage.

David

 

[Herfried K. Wagner [MVP]]

Alright, so I'm messing around with some code, and I
brought up a good question to myself.

If creating a class called "Person", and filling that class with variables,
properties like:

Public Class Person
Private mstrName As String
Private mdtBirthDate As Date

Public Property Name() As String
Get
Return mstrName
End Get
Set(ByVal Value As String)
mstrName = Value
End Set
End Property

etc......

What is the benefit of typing out all that code over defining a simple
structure such as:

Structure Person
Public Name As String
Public BirthDate As Date
End Structure

Using properties instead of public variables has the advantage that you can
add code that checks a property's value when it is set. In addition to
that, properties should be used to model "attributes" of an entity (class).

Structures only make sense when their size is small (they are value types
opposed to classes which are reference types), or when it is important to
make them persistent more easily. In this particular case I would prefer a
class over a structure.

 

[OpticTygre]

Great comments from everyone. I suppose it differs on the application
purpose. Classes with it's internal properties would obviously be better if
planning on using an object repeatedly, whereas a structure might be better
if the object was small, and was only going to be used once or twice during
an application. That's pretty much what I gather from what everyone has
said.

-Jason