VBA Class: Variables


VBA Class Variables

Private and Public variables

Classes are datatypes.

A class is a special datatype because it can contain both variables and routines.

Image showing the three basic class types, type 1

The variables can be Private or Public.

Image showing the public and private components of a class
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.

Image showing the relation between public and private components of a class and the interface of a 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.

Image showing a VBA logger class

Here is the interface of the class.

Image showing using a VBA logger instance

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.

Image showing using a VBA logger instance, badly designed

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.

Image showing using a VBA logger instance, badly designed

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.

There are three kinds of variables in the sub Flush.

Name of variableKind of variable
DoItAlwaysAn argument of the routine
FileIndexA 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.