VBA Class Variables
Private and Public variables
Classes are datatypes.
A class is a special datatype because it can contain both variables and routines.
The variables can be Private or Public.
By default, variables in a class should be Private. Private variables can only be used by the routines of the class. From inside the class (and only from inside the class), they act as global variables. The only way to change them, from outside the class, is by using Public routines. They are not part of the interface of the class. Private variables are encapsulated by the class.
Exceptionally, variables in a class can be Public too. Declaring variables in the class as Public is considered to be bad practice. Object oriented principles dictate that variables inside a class should be Private and approachable only through Public routines.
Example: Public versus Private
If you have some time, spend a few minutes to study the following code. It is a class implementing a simple logger.
Here is the interface of the class.
First, do you see the relation between the class definition and its interface?
It is very simple: all variables and routines that are Public are part of the interface. All the variables are Private and none of them are in the interface. The class variables all end with "_" and there are no things ending with "_" in the interface. As you can see for the Property routines, by default, a routine in a class is Public.
Now focus on the variable Message_.
Note that the only way to change the variable Message_ is by calling the public sub ToLog. And, once something is put in the variable Message_, there is NO way of preventing that the content of the variable Message_ will end up in the log file (... except if you would crash the VBA memory of course). As a class designer, this should make you happy. It is an example of good design.
Now imagine we make all the variables Public.
Then, this is the interface.
Again focus on the variable Message_.
Now, as a class designer, you are not sure anymore that once something ends up in the variable Message_, it will end up in the file, opening up opportunities for uncareful or malicious users of your VBA class. The problem is that the following code works perfectly.
This is not good design.
Example (continued): Naming conventions for variables
There are different kinds of variables in a class. Things can get confusing. Have a look at this private sub Flush.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Private Sub Flush(Optional ByVal DoItAlways As Boolean = False) If ((Len(Message_) > FlushAsOfThisNumberOfCharacters_) Or DoItAlways) Then Dim FileIndex As Integer FileIndex = FreeFile() Open PathOfLogFile_ & NameOfLogFile_ For Append As #FileIndex Print #FileIndex, Message_ Close #FileIndex Message_ = "" End If End Sub |
There are three kinds of variables in the sub Flush.
| Name of variable | Kind of variable |
|---|---|
DoItAlways | An argument of the routine |
FileIndex | A local variable in the routine |
Message_ | A class variable |
Many programmers use a small personal convention in naming the variables to help to make the distinction. You might have noticed that all our VBA class variables end with _. We do not have a naming convention to distinguish between local variables and arguments, though I have seen VBA programmers that also here use a small naming convention. If it helps, why not? There exist naming conventions standards, but, in VBA, you are free to choose whatever you like. Do it. It helps to make your VBA code more readable.