A class is a programming entity that gathers together all of the data and behavior that characterizes some sort of programming abstraction. It wraps the abstraction in a nice, neat package with well-defined interfaces to outside code. Those interfaces determine exactly how code outside of the class can interact with the class. A class determines which data values are visible outside of the class and which are hidden. It determines the routines that the class supports and their availability (visible or hidden).
A class defines properties, methods, and events that let the program work with the class:
For a concrete example, imagine a Job class that represents a piece of work to be done by an employee. This class might have the properties shown in the following table.
PROPERTY | PURPOSE |
JobDescription | A string describing the job |
EstimatedHours | The number of hours initially estimated for the job |
ActualHours | The actual number of hours spent on the job |
Status | The job’s status (New, Assigned, In Progress, or Done) |
ActionTaken | A string describing the work performed, parts installed, and so forth |
JobCustomer | An object of the Customer class that describes the customer for whom the job is performed (name, address, phone number, service contract number, and so on) |
AssignedEmployee | An object of the Employee class that describes the employee assigned to the job (name, employee ID, Social Security number, and so on) |
The JobDescription, EstimatedHours, ActualHours, Status, and ActionTaken properties are relatively simple string and numeric values. The JobCustomer and AssignedEmployee properties are objects themselves with their own properties, methods, and events.
This class might provide the methods shown in the following table.
METHOD | PURPOSE |
AssignJob | Assign the job to an employee |
PrintInvoice | Print an invoice for the customer after the job is finished |
EstimatedCost | Calculate and return an estimated cost based on the customer’s service contract type and EstimatedHours |
The class could provide the events shown in the following table to keep the main program informed about the job’s progress.
EVENT | PURPOSE |
Created | Occurs when the job is first created |
Assigned | Occurs when the job is assigned to an employee |
Rejected | Occurs if an employee refuses to do the job, perhaps because the employee doesn’t have the right skills or equipment to do the work |
Canceled | Occurs if the customer cancels the job before it is worked |
Finished | Occurs when the job is finished |
In a nutshell, a class is an entity that encapsulates the data and behavior of some programming abstraction such as a Job, Employee, Customer, LegalAction, TestResult, Report, or just about anything else you could reasonably want to manipulate as a single entity.
After you have defined a class, you can create instances of the class. An instance of the class is an object of the class type. For example, if you define a Job class, you can then make an instance of the class that represents a specific job, perhaps installing a new computer for a particular customer. The process of creating an instance of a class is called instantiation.
There are a couple of common analogies to describe instantiation. One compares the class to a blueprint. After you define the class, you can use it to create any number of instances of the class, much as you can use the blueprint to make any number of similar houses (instances).
Another analogy compares a class definition to a cookie cutter. When you define the cookie cutter, you can use it to make any number of cookies (instances).
Note that Visual Basic is jam-packed with classes. Every type of control and component (Form, TextBox, Label, Timer, ErrorProvider, and so forth) is a class. The parent classes Control and Component are classes. Even Object, from which all other classes derive, is a class. Whenever you work with any of these (getting or setting properties, calling methods, and responding to events), you are working with instances of classes.
Because all of these ultimately derive from the Object class, they are often simply called objects. If you don’t know or don’t care about an item’s class, you can simply refer to it as an object.
The following sections, which describe some of the features that OOP languages in general and Visual Basic in particular, add to this bare-bones definition of a class.