View Full Version : Class property vs public variable

03-19-2008, 09:06 AM

My question is conceptual, and is about the difference between a property and a public variable of a class.

Let's say I'm creating a new object class on a Class Module.
I can use
Dim MP As String
Property Let MyProperty(Value As String)
MP = Value
End Property

Public MyProperty As String
In both cases, MyProperty is available from outside of the class.
What are then the advantages/disadvantages of them? In what cases is either one of them advisable over the other?



Bob Phillips
03-19-2008, 10:05 AM
In the first, the property is write only, in the latter it is read/write property. If you just used Get, it would be read only.

I alwasy use the former style myself, and it has the advantage that you can process the passed value. So for instance, you could get a employee grade, and from that you can calculate the slary in the Get procedure.

03-20-2008, 02:42 AM
Thanks Bob. (Again ;))

Now, sticking to your example, where do you put the calculation of salary?
Into the Property Let EmpGrade part?
Or into the Property Get Salary part?I guess they're all the same, but maybe one of them is better for some reason.

Another thing is, when you want to validate the data that is passed on to the instance of the class.

E.g. EmpGrade should be 1, 2, 3, 4 or 5, any other values should be rejected. Where do you put the validation code?
Incorporate it into the object class, e.g. into Property Let EmpGrade part?
Or leave it outside the class, so that it's the main program's job to make sure that only valid data is passed on to the object?Is there a "Best Practice" for these things?


Bob Phillips
03-20-2008, 03:00 AM
Deep philosophical questions Jimmy <G>

My answer is a tad vague, but really you have to look at the business process, and the rules surrounding the object that the class is emulating. So in our example, let us say that the company employs people so we are going to create an employee class (with an employee collection class of course, but that is the next level). Now every employee has a name of course, so this is a simple read/write proeprty set for given and surnames. The company will have a system of iding the individual that will be unique (names are not), so this will be generated from within the class when a new employee is added (this would normally require vsiisting some external data source to get the next id, or some genarting algorithm).

As to the salary, you have to ask what is the criteria for determing the salary. If it were so simplistic as say a combination of Grade and Years Served, I would add coe to each of the Let property preocedures to calculate the Salary, as long as the other one is set. I would not do it in the Get procedure (that was a typo in my previous post), because it is likely the class needs that info, calculate pay rise for instance, so you would save it in a private class variable, calculate once, not recalculate every time.

As to whether to validate within the class or outwith the class, I tend to keep the classes pure. In other words, if you use the class, you make sure that you know the API, and that you conform to it. If you don't, be it on your head (a bit like Windows API calls <G>). This way I can keep the class simple, concentrating on what it is about, the custom object it represents.

03-20-2008, 03:49 AM
To generalize xld's responses, in a public variable, you are passing a value. In a property procedure, you are passing a value and you have the opportunity to run additional code within the procedure. You can process the value, validate the value, calculate other values, change the layout of a user form, or whatever else you may want to do.

03-20-2008, 05:37 AM
Deep philosophical questions Jimmy
Yes, well, as I'm getting comfortable with classes, I'm also developing such questions. I still have to digest your answers, but it is sure as sunlight that you gave me some interesting points to consider. My opinion might change, but right now I think your last paragraph will stay with me forever ;)

I thank you as well for clearing up a bit of my confusion. :thumb


My immediate questions are answered, but I think I'll leave this thread open for future ones. I plan to have some :yes