Chapter 1. Introduction

only for RuBoard

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 actiondifferent 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?

Consider that light bulb on the back porch. The filament in the bulb is nothing more than a simple resistor. When the 100-watt bulb is "on," the filament's temperature is about 2550 degrees Celsius. The resulting thermal radiation, which is proportional to the length of the filament (but not the diameter), produces about 1750 lumens worth of visible light at a wavelength of about 555 nanometers. And by the way, the filament is made out of tungsten.

Do you really want to know these minute details, or do you just want the light to come on when you flick the switch?

Any object has two inherent properties: state and behavior . The light bulb on the back porch has state. It can be on or off. It has a brand name and a life expectancy. It has been in use for a certain number of hours. It has a specified number of hours left before the irregular evaporation of its tungsten filament causes it to burn out. Behaviorally, it provides light; it shines.

But an object is rarely an island unto itself.

Many objects participate collectively in a system. The television and surrounding sound speakers are a part of a system called a home theater. The refrigerator and oven belong to a system called a kitchen. These systems, in turn , are a part of a larger system that is called an apartment. Collections of apartments make up a system known as a complex. Apartments and houses belong to neighborhoods and so on, ad infinitum.

In essence, this book discusses systems. Building and designing objects is one aspect of this process of building a system. Determining how these objects interact with one another is another. Understanding both phases of development is crucial when building any system that has more than a modicum of complexity.

Generally, you can think of this process of developing a system as object-oriented programming and object-oriented design. Specifically, though, you are really working toward an understanding of the objects you build and the system in which they participate. Component-based programming forms the basis of this system.

Programming objects in software doesn't require an object-oriented language, and just because you use an object-oriented programming language doesn't mean that your code is object-oriented. Languages can only assist the process; they can't make any guarantees . The ability to write object-oriented software was always available with VB. Writing it just hasn't always been easy because the language wasn't always oriented in that direction. Developing binary reusable components in VB has been possible for some time now, but using these components across languages used to be considered somewhat of a black artuntil now.

Today, Visual Basic .NET is a cutting-edge, object-oriented language that runs inside of a state-of-the-art environment. It is feature-rich and designed to take advantage of the latest developments in object-oriented programming. Writing software and building components has never been easier.

only for RuBoard