In most object-oriented languages, an object can share data with other objects of the same class. For example, each object might need a count of how many other objects of the same type exist. An object might behave differently if it is the last object, or it might refuse to be created if there are too many objects. Visual Basic does not provide a direct means of sharing data between instances, but you can fake it using Public variables in a standard module. There is only one instance of a Public (global) variable, and all instances of a class can access it. But so can any other module in your project. In other words, this system violates all standards of encapsulation decency. It works, but only if everyone behaves themselves.
Do you trust other people to always behave? Do you trust yourself? Neither do I.
Now, in defense of using Public variables in standard modules to communicate between instances, keep in mind that these variables are visible only inside a component. If you behave yourself inside your component, users of the component won’t be able to get inside and find those Public variables that aren’t supposed to be public. Of course, if you’re using a bunch of private classes inside an EXE, you are the component and everything is visible. You just have to remember that Public isn’t supposed to mean public.
The other disadvantage is that you end up with a lot of dummy standard modules that serve no purpose other than to get around limitations of the encapsulation model. You’ll be seeing a lot of this in coming sections.