Encapsulation means bringing data to life. Instead of you, the outsider, manipulating data by calling functions that act on it, you create objects that take on lives of their own, calling each other’s methods, setting each other’s properties, sending messages to each other, and generally interacting in ways that more closely model the way objects interact in real life. Early versions of Visual Basic allowed you to use objects that were created in other languages; version 4 allowed you to create your own objects, although there were significant holes in the encapsulation model.
Visual Basic version 5 has got most of encapsulation right on the second try. Big problems with public constants have been fixed by the Enum statement. You can now set a default property or method (although it’s unnecessarily difficult), and you can create collections (but that’s even harder). Property procedures give Visual Basic an edge over C++ and many other object-oriented languages in the way they allow you to access data with a natural syntax—and without exposing internal data to unauthorized changes.
Visual Basic still lags behind other object-oriented languages in the way it allows data sharing between classes and between instances of the same class. The new Friend modifier allows you to share data between classes, but the design is debatable. On the one hand, it allows you to specify exactly what you want to share with other classes (unlike some languages that say if you share any private part of a class you share all of it). On the other hand, the Friend modifier doesn’t allow you to specify with whom you’re sharing data within a project (unlike other languages that allow you to specify who your friends are).
Visual Basic provides no language feature for sharing data between instances of an object (static variables in C++), but you can fake it with public variables in what Visual Basic still quaintly calls “standard” modules (“irregular” modules would be a better term). This hack exposes your data not only to multiple instances of an object, but to any other module that wants to see it. When you create a public class or control, friend members and public variables in standard modules within the project become invisible to clients outside the component, so there is some protection. But it’s a kind of accidental feature that isn’t up to the carefully designed protection schemes of C++ or Java, which provide protection for all classes, not just those in components. The protection mechanism isn’t the most important feature of a language, but I still have to deduct points for an inferior design.
The biggest problem in Visual Basic encapsulation is its inability to initialize an object in its declaration. Unless your object can be successfully initialized with default properties, it will be invalid from the time it is created until the time you initialize the key data properties. This isn’t a big problem with controls, which have property pages as their initialization mechanism. It is a big problem for most other objects, which must be initialized through some convention defined by the class designer. Convention is not a reliable way to create rock-solid objects. Despite the seriousness of this limitation (which you’ll hear a lot more about), I don’t deduct much for it because lack of initialization syntax is a fault of the language, not just of classes. You can’t initialize an Integer any more than you can initialize a CMyClass object. If I were going to rate Visual Basic as a general language, I’d list this as its most serious limitation.
Rating for encapsulation: .8