Visual Basic 2005 with .NET 3.0 Programmer's Reference
This chapter explains the fundamental ideas behind object-oriented programming (OOP). It describes the three main features of OOP languages: encapsulation, inheritance, and polymorphism. It explains the benefits of these features and describes how you can take advantage of them in Visual Basic.
This chapter also describes method overloading. In a sense, overloading provides another form of polymorphism. It lets you create more than one definition of the same class method, and Visual Basic decides which version to use based on the parameters the program passes to the method.
Many of the ideas described in this chapter will be familiar to you from your experiences with forms, controls, and other building blocks of the Visual Basic language. Those building blocks are object-oriented constructs in their own rights, so they provide you with the benefits of encapsulation, inheritance, and polymorphism whether you knew about them or not.
Classes
A class is a programming entity that gathers all 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:
-
A property is some sort of data value. It may be a simple value (such as a name or number), or it may be a more complex item (such as an array, collection, or object containing its own properties, methods, and events).
-
A method is a subroutine or function. It is a piece of code that makes the object defined by the class do something.
-
An event is an action notification defined by the class. An event calls some other piece of code to tell it that some condition in a class object has occurred.
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 (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 |
BillJob | Print an invoice for the customer after the job is finished |
EstimatedCost | Returns 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 the specific job of installing a new computer for a particular customer. The process of creating an instance 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.
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.
Note that Visual Basic is jam-packed with classes. Every type of control and component (Form, TextBox, Label, Panel, GroupBox, Button, PictureBox, Timer, 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.
Tip | When you read the section “Polymorphism” later in this chapter, you’ll see that this makes technical as well as intuitive sense. Because all classes eventually derive from the Object class, all instances of all classes are in fact Objects. |
The following sections describe some of the features that OOP languages in general, and Visual Basic in particular, add to this bare-bones definition of a class.
Категории