Most tutorials (including tutorials on this site) about programming a class will emphasize the Property statement and how it works with the Class constructors (the New subroutines) to instantiate the class. Here's the really, really short version, just to set the stage. (The "auto-implemented" property syntax introduced with VB.NET 2010 is used here.)
... the Class
Public Class theClass
Property ExampleProperty As String
Public Sub New(ByVal exampleProperty As String)
Me.ExampleProperty = exampleProperty
End Sub
End Class
... Instantiating the Class
Dim aClass As New theClass("The Property Value")
The question is, what is the difference if you just code a Public variable instead of a Property:
Public Class theClass
Public ExampleProperty As String
...
Answer: No difference. Go right ahead.
You only need a Property if you have processing, such as a calculated value or validation in the class. In fact, coding a Property can be slightly more trouble. If you need a "ReadOnly" property, you must code a Get subroutine too. But you can code a Public variable without one and it performs just like a Property.
Public ReadOnly ExampleProperty As String
Addendum: A couple of the best contributors to this site weighed in with objections to my conclusions. They make some good points. Here's what John Anthony Oliver wrote:
The answer is wrong (or not 100 % correct) for 2 reasons:
- It goes against the OOP (object orientated programming) principle of encapsulation.
- If you do not use the keyword PROPERTY then the item will not show in the property grid for a custom control class.
In reviewing the recent book, Seven Languages in Seven Weeks, I wrote: "Whether a language is really object oriented or not has been a war zone for decades. Bruce Tate says he gets hate mail from programmers whose favorite language wasn't included in this book." But the point about the property grid really is something I overlooked so I thank John for pointing it out.
My main point was not to suggest this as a preferred coding technique, but rather to clear up the confusion about just what a property is. Once you realize that, except for any other processing that may be required, it's just like a public variable, the way the whole thing fits together is more clear. Hope I did that ... for somebody anyway.
---------
Bug alert ... I've used the fairly common practice (Murach uses it in their latest book, "VB.NET 2010" for example) of making the leading character of the property name upper case - ExampleProperty - and the leading character of the parameter in the New constructor lowercase - exampleProperty - to make a point. What happens if you forget to code "Me." in front of ExampleProperty in the New constructor?
ExampleProperty = exampleProperty
Answer: ExampleProperty in the instance of the class - aClass in this code - just fails to retain the value. There's no error message in the compile. The code doesn't throw an exception. ExampleProperty in the instantiated object is just "Nothing". Normally (but not always) Intellisense will convert the leading character to lowercase - that is, ExampleProperty will automatically change to exampleProperty after you type it - so you at least have something in the code to notice. But in some cases (such as when you copy and paste, instead of typing, the name) that doesn't happen. This can mess you up if you fail to notice it. You can tear your hair out asking, "Why doesn't the New constructor work???"
This doesn't happen if you use different names. "Me." isn't required then and it works fine.
Public Property George As String
Public Sub New(ByVal exampleProperty As String)
George = exampleProperty
End Sub
This is a good argument for using more obviously different names.
---------