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

"OpticTygre" <(E-Mail Removed)> wrote
> 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

"Larry Serflaten" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "OpticTygre" <(E-Mail Removed)> wrote
>> 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).
>


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

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

"Larry Serflaten" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "OpticTygre" <(E-Mail Removed)> wrote
>> 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
>

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

"OpticTygre" wrote:

> 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
>
>
>

"OpticTygre" <(E-Mail Removed)> wrote in message
news:RLSdne5E0e-hieHcRVn-(E-Mail Removed)...
> 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

"OpticTygre" <(E-Mail Removed)> schrieb:
> 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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

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

"Herfried K. Wagner [MVP]" <hirf-spam-me-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "OpticTygre" <(E-Mail Removed)> schrieb:
>> 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.
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>
>
>