What's the point of fields?

I'm learning VB.Net with a view to converting from VB6. One simple
detail I'm unsure of concerns fields (as class members).

In VB6 I'd thought that declaring a class property just as a public
variable (ie without get/set procedures) was deprecated though valid.
I'm slightly surprised to see this same approach also turning up in
what is generally the more formalised structure of .Net and even
apparently being approved of with the title of a field or class field,
while still seemingly functioning as a standard property.

Have I misunderstood something about how fields are now to be used in
..Net, or does a field remain a simple substitute for a full property
declaration that wouldn't necessarily be used in well structured code?

TIA
John Dann

re: What's the point of fields?

In my humble opinion, non-private fields should be frowned upon because they
throw encapsulation to into the bin. However you still need private fields
to actually store data in your class - if you didn't have private fields in
your class, it would essentially be a stateless object.

HTH,

Trev.

"John Dann" <news@prodata.co.uk> wrote in message
news:j2ri00tcttunrsl43vbg46d73dv4jhtp9g@4ax.com...[color=blue]
> I'm learning VB.Net with a view to converting from VB6. One simple
> detail I'm unsure of concerns fields (as class members).
>
> In VB6 I'd thought that declaring a class property just as a public
> variable (ie without get/set procedures) was deprecated though valid.
> I'm slightly surprised to see this same approach also turning up in
> what is generally the more formalised structure of .Net and even
> apparently being approved of with the title of a field or class field,
> while still seemingly functioning as a standard property.
>
> Have I misunderstood something about how fields are now to be used in
> .Net, or does a field remain a simple substitute for a full property
> declaration that wouldn't necessarily be used in well structured code?
>
> TIA
> John Dann[/color]

re: What's the point of fields?

John,
In addition to Trev's comments, it has not been deprecated as much as it is
discouraged.

Interesting enough this topic was just discussed on 1/16/2004, search this
newsgroup for a thread titled "Public properties vs. public variables".

IMHO it is better to make your fields Private and use Properties as it
promotes encapsulation.

Remember Encapsulation is one of the top 3 tenants of OOP. The other 2 being
Inheritance and Polymorphism.

Properties are .NET method of encapsulating field or attribute data.

There are Code Critics & Analyzers that you can purchase that will review
your code and identify if you have Non-Private fields as well as other
discouraged practices. Such as
http://www.fmsinc.com/reviews/tnanalyzer/sd1202.htm

Hope this helps
Jay

"John Dann" <news@prodata.co.uk> wrote in message
news:j2ri00tcttunrsl43vbg46d73dv4jhtp9g@4ax.com...[color=blue]
> I'm learning VB.Net with a view to converting from VB6. One simple
> detail I'm unsure of concerns fields (as class members).
>
> In VB6 I'd thought that declaring a class property just as a public
> variable (ie without get/set procedures) was deprecated though valid.
> I'm slightly surprised to see this same approach also turning up in
> what is generally the more formalised structure of .Net and even
> apparently being approved of with the title of a field or class field,
> while still seemingly functioning as a standard property.
>
> Have I misunderstood something about how fields are now to be used in
> .Net, or does a field remain a simple substitute for a full property
> declaration that wouldn't necessarily be used in well structured code?
>
> TIA
> John Dann[/color]

re: What's the point of fields?

OK - many thanks for the comments. So I conclude that, as with
recommended VB6 usage, simple variables inside classes in .Net are
best declared with private scope. And for class properties, a formal
property declaration block is the best route.

This is as I would have expected - it was just the introduction of the
field terminology that was making me wonder.

Thanks
JGD

re: What's the point of fields?

John,
You are concluding correctly.

In case you haven't noticed you can also mark your fields Readonly now and
have them set in the constructor, which is useful for values that are
"constant" per instance of the class.

Public Class Person

Private Readonly m_id As Integer

Public Sub New(ByVal id As Integer)
m_id = id
End Sub

Public Readonly Property ID() As Integer
Get
Return m_id
End Get
End Property

End Class

Allows you to set the ID property when you create an instance of the Person
class, however once you have a Person object, you cannot change its ID, even
within the class itself!

Note you can also have Shared Readonly fields that are like Const variables,
only the value can be determined at run time. These can be set in the Shared
Sub New.

Hope this helps
Jay

"John Dann" <news@prodata.co.uk> wrote in message
news:v7lk00hqv90gs7prjsp227bf19url58ul6@4ax.com...[color=blue]
> OK - many thanks for the comments. So I conclude that, as with
> recommended VB6 usage, simple variables inside classes in .Net are
> best declared with private scope. And for class properties, a formal
> property declaration block is the best route.
>
> This is as I would have expected - it was just the introduction of the
> field terminology that was making me wonder.
>
> Thanks
> JGD[/color]