22-01-2013, 11:40 AM
Object-Oriented Programming with Visual Basic .NET
1Object-Oriented.pdf (Size: 532.4 KB / Downloads: 129)
Introduction
To understand the world of object-oriented programming, look at the world around
you for a moment. You might see vacuum cleaners, coffee makers, ceiling fans, and a
host of other objects. Everywhere you look, objects surround you.
Some of these objects, such as cameras, operate independently. Some, such as telephones
and answering machines, interact with one another. Some objects contain
data that persists between uses, like the address book in a cell phone. Some objects
contain other objects, like an icemaker inside of the freezer.
Many objects are similar in function but different in purpose. Bathtubs and kitchen
sinks, for example, both provide water and are used for cleaning. But it is a rare occasion
when you will take a bath in the kitchen sink or wash your dishes in the tub.
However, the bathtub and the kitchen sink in your house probably share the same
plumbing. Certainly, they share a common interface: hot and cold water knobs, a
faucet, and a drain.
When you think about it, what is the difference between a sink and a bathtub? The
location? The size of the basin? Their heights off the ground? How many more similarities
are there than differences?
Sometimes the same action causes an object to do different things depending on the
context of the situation. When you press Play on the remote, the DVD might play a
movie on the television. But if a CD is in the player, it plays music out of the speakers.
Same button, same action—different results. When you flip the switch on the
back porch, the light comes on. But the switch in the kitchen turns on the garbage
disposal. You use the same kind of switch, but obtain different results.
You can think about many objects around you in terms of black boxes. You comprehend
the fundamentals of these objects and possess a basic understanding of what
makes them work, but the specifics of their operation are unknown to you. And you
like it that way. Do you really want to have to know the inner mechanisms of every
object in your house in order to use it?
Visual Basic .NET and Object-Oriented
Programming
Visual Basic .NET is a fully object-oriented programming language, which means it
supports the four basic tenets of object-oriented programming: abstraction, encapsulation,
inheritance, and polymorphism.
We have already conceptualized many of these object-oriented concepts by just looking
at the objects that surround us in our everyday lives. Let’s look more closely at
these terms and see what they actually mean and what they do for developers of
object-oriented software.
Abstraction
A radio has a tuner, an antenna, a volume control, and an on/off switch. To use it,
you don’t need to know that the antenna captures radio frequency signals, converts
them to electrical signals, and then boosts their strength via a high-frequency amplification
circuit. Nor do you need to know how the resulting current is filtered,
boosted, and finally converted into sound. You merely turn on the radio, tune in the
desired station, and listen. The intrinsic details are invisible. This feature is great
because now everyone can use a radio, not just people with technical know-how.
Hiring a consultant to come to your home every time you wanted to listen to the
radio would become awfully expensive. In other words, you can say that the radio is
an object that was designed to hide its complexity.
Encapsulation
Programming languages like C and Pascal can both produce object-like constructs.
In C, this feature is called a struct; in Pascal, it is referred to as a record. Both are
user-defined data types. In both languages, a function can operate on more than one
data type. The inverse is also true: more than one function can operate on a single
data type. The data is fully exposed and vulnerable to the whims of anyone who has
an instance of the type because these languages do not explicitly tie together data
and the functions that operate on that data.
In contrast, object-oriented programming is based on encapsulation. When an
object’s state and behavior are kept together, they are encapsulated. That is, the data
that represents the state of the object and the methods (Functions and Subs) that
manipulate that data are stored together as a cohesive unit.
Encapsulation is often referred to as information hiding. But although the two terms
are often used interchangeably, information hiding is really the result of encapsulation,
not a synonym for it. They are distinct concepts. Encapsulation makes it possible
to separate an object’s implementation from its behavior—to restrict access to its
internal data. This restriction allows certain details of an object’s behavior to be hidden.
It allows us to create a “black box” and protects an object’s internal state from
corruption by its clients.
Inheritance
Inheritance is the ability to define a new class that inherits the behaviors (and code)
of an existing class. The new class is called a child or derived class, while the original
class is often referred to as the parent or base class.
Inheritance is used to express “is-a” or “kind-of” relationships. A car is a vehicle. A
boat is a vehicle. A submarine is a vehicle. In OOP, the Vehicle base class would provide
the common behaviors of all types of vehicles and perhaps delineate behaviors
all vehicles must support. The particular subclasses (i.e., derived classes) of vehicles
would implement behaviors specific to that type of vehicle. The main concepts
behind inheritance are extensibility and code reuse.
Polymorphism
Polymorphism refers to the ability to assume different forms. In OOP, it indicates a
language’s ability to handle objects differently based on their runtime type.
When objects communicate with one another, we say that they send and receive messages.
The advantage of polymorphism is that the sender of a message doesn’t need
to know which class the receiver is a member of. It can be any arbitrary class. The
sending object only needs to be aware that the receiving object can perform a particular
behavior.
A classic example of polymorphism can be demonstrated with geometric shapes.
Suppose we have a Triangle, a Square, and a Circle. Each class is a Shape and each
has a method named Draw that is responsible for rendering the Shape to the screen.
With polymorphism, you can write a method that takes a Shape object or an array of
Shape objects as a parameter (as opposed to a specific kind of Shape). We can pass
Triangles, Circles, and Squares to these methods without any problems, because
referring to a class through its parent is perfectly legal. In this instance, the receiver is
only aware that it is getting a Shape that has a method named Draw, but it is ignorant
of the specific kind of Shape. If the Shape were a Triangle, then Triangle’s version of
Draw would be called. If it were a Square, then Square’s version would be called, and
so on.