Classes and Objects

Since Microsoft Visual Basic 4 introduced the concept of class modules, a furious debate has raged among Visual Basic developers about the object-oriented nature of the language. Is Visual Basic a real object-oriented programming (OOP) language? Is it just an object-based language? Or is it somewhere between these two extremes?
Visual Basic definitively is not a true OOP language and it won’t be one until it possesses some essential OOP features, such as inheritance. But this deficit shouldn’t excuse your not learning in depth what classes and objects have to offer developers:
• Class modules can immensely improve your productivity, help you solve many common and intricate programming problems, and even permit you to perform tasks that would be extremely difficult, if not impossible, otherwise.
• Even if Visual Basic isn’t a full-fledged object-oriented programming language, you can still use its classes to better organize your code into truly reusable modules and design your applications entirely using concepts derived from the Object-Oriented Design discipline. In this sense, the inclusion of a tool such as Visual Modeler in the Enterprise Edition is a clear sign of Microsoft’s will to pursue this goal.
Most important, objects are the base on which almost every feature of Visual Basic is implemented. For example, without objects you can’t do serious database programming, you can’t deliver Internet applications, and you can’t write components for COM, DCOM, or MTS. In short, you can do little or nothing without a firm grasp on what objects are and how you can take advantage of them.
If you’ve ever read books or articles about OOP, you surely found dozens of different definitions for the term object. Most of the definitions are correct and confusing at the same time. The definition I like most is this one:
An object is an entity that embeds both data and the code that deals with it.
Let’s see what this means in practice.
The Basic Concepts
A very short explanation is in order. A class is a portion of the program (a source code file, in Visual Basic) that defines the properties, methods, and events—in a word, behavior—of one or more objects that will be created during execution. An object is an entity created at run time, which requires memory and possibly other system resources, and is then destroyed when it’s no longer needed or when the application ends. In a sense, classes are design time–only entities, while objects are run time–only entities.
Your users will never see a class; rather, they’ll probably see and interact with objects created from your classes, such as invoices, customer data, or circles on the screen. As a programmer, your point of view is reversed because the most concrete thing you’ll have in front of you while you’re writing the application is the class, in the form of a class module in the Visual Basic environment.
Until you run the application, an object isn’t more real than a variable declared with a Dim statement in a code listing.