Abstraction means, simply, to filter out an object's properties and operations until just the ones you need are left. What does “just the ones you need” mean?

Different types of problems require different amounts of information, even if those problems are in the same general area. In the second pass at building a washing machine class, more attributes and operations emerged than in the first pass. Was it worth it?

If you're part of a development team that's ultimately going to create a computer program that simulates exactly how a washing machine does what it does, it's definitely worth it. A computer program like that (which might be useful to design engineers who are actually building a washing machine) has to have enough in it to make accurate predictions about what will happen when the washing machine is built, fully functioning, and washing clothes. For this kind of program, in fact, you can filter out the serialNumber attribute because it's probably not going to be very helpful.

What if, on the other hand, you're going to create software to track the transactions in a laundry that has a number of washing machines? In this program you probably won't need all the detailed attributes and operations mentioned in the preceding section. You might, however, want to include the serialNumber of each washing machine object.

In any case, what you're left with, after you've made your decisions about what to include and what to exclude, is an abstraction of a washing machine.

A Critical Skill

Some authorities argue that abstraction—that is, knowing what to include in a model and what to leave out—is the most critical skill for a modeler.

Washing machines, refrigerators, microwave ovens, toasters, dishwashers, radios, waffle makers, blenders, and irons are all appliances. In the world of object orientation, we would say that each one is a subclass of the Appliance class. Another way to say this is that Appliance is a superclass of all those others.

Appliance is a class that has the attributes onOffSwitch and electricWire, and the operations turnOn() and turnOff(). Thus, if you know something is an appliance, you know immediately that it has the Appliance class's attributes and operations.

Object-orientation refers to this relationship as inheritance. Each subclass of Appliance (WashingMachine, Refrigerator, Blender, and so on) inherits the features of Appliance. It's important to note that each subclass adds its own attributes and operations. Figure 2.3 shows the superclass-subclass relationship.

Figure 2.3. Appliances inherit the attributes and operations of the Appliance class. Each one is a subclass of the Appliance class. The Appliance class is a superclass of each subclass.

Inheritance doesn't have to stop there. Appliance, for example, is a subclass of the HouseholdItem class. Furniture is another subclass of HouseholdItem, as Figure 2.4 shows. Furniture, of course, has its own subclasses.

Figure 2.4. Superclasses can also be subclasses and inherit from other superclasses.

Sometimes an operation has the same name in different classes. For example, you can open a door, you can open a window, and you can open a newspaper, a present, a bank account, or a conversation. In each case you're performing a different operation. In object-orientation each class “knows” how that operation is supposed to take place. This is called polymorphism (see Figure 2.5).

Figure 2.5. In polymorphism an operation can have the same name in different classes, and proceed differently in each class.

At first look it would seem that this concept is more important to software developers than to modelers. After all, software developers have to create the software that implements these methods in computer programs, and they have to be aware of important differences among operations that might have the same name. And they can build software classes that “know” what they're supposed to do.

But polymorphism is important to modelers, too. It allows the modeler to speak to the client (who's familiar with the slice of the world to be modeled) in the client's own words and terminology. Sometimes that terminology naturally leads to operation words (like “open”) that can have more than one meaning. Polymorphism enables the modeler to maintain that terminology without having to make up artificial words to maintain an unnecessary (and unnatural) uniqueness of terms.

In a TV commercial that aired a few years ago, two people discuss all the money they'll save if they dial a particular seven-digit prefix before dialing a long-distance phone call.

One of them asks, incredulously, “How does that work?”

The other replies: “How does popcorn pop? Who cares?”

That's the essence of encapsulation: When an object carries out its operations, those operations are hidden (see Figure 2.6). When most people watch a television show, they usually don't know or care about the complex electronics components that sit in back of the TV screen and all the many operations that have to occur in order to paint the image on the screen. The TV does what it does and hides the process from us. Most other appliances work that way, too. (Thankfully!)

Figure 2.6. Objects encapsulate what they do. That is, they hide the inner workings of their operations from the outside world and from other objects.

Why is this important? In the software world, encapsulation helps cut down on the potential for bad things to happen. In a system that consists of objects, the objects depend on each other in various ways. If one of them happens to malfunction and software engineers have to change it in some way, hiding its operations from other objects means that it probably won't be necessary to change those other objects.

Turning from software to reality, you see the importance of encapsulation in the objects you work with, too. Your computer monitor, in a sense, hides its operations from your computer's CPU. When something goes wrong with your monitor, you either fix the monitor or replace it. You probably won't have to fix or replace the CPU along with it.

While we're on the subject, here's a related concept. Because encapsulation means that an object hides what it does from other objects and from the outside world, encapsulation is also called information hiding. But an object does have to present a “face” to the outside world so you can initiate those operations. The TV, for example, has a set of buttons either on the TV itself or on a remote. A washing machine has a set of dials that enable you to set temperature and water level. The TV's buttons and the washing machine's dials are called interfaces.

I've mentioned that in a system, objects work together. They do this by sending messages to one another. One object sends another a message—a request to perform an operation, and the receiving object performs that operation.

A TV and a remote present a nice intuitive example. When you want to watch a TV show, you hunt around for the remote, settle into your favorite chair, and push the On button. What happens? The remote-object sends a message (literally!) to the TV-object to turn itself on. The TV-object receives this message, knows how to perform the turn-on operation, and turns itself on. When you want to watch a different channel, you click the appropriate button on the remote, and the remote-object sends a different message—“change the channel”—to the TV-object. The remote can also communicate with the TV via other messages for changing the volume, muting the volume, and setting up closed captioning.

Let's go back to interfaces for a moment. Most of the things you do from the remote you can also do by getting out of the chair, going to the TV, and clicking buttons on the TV. (You might actually try that sometime!) The interface the TV presents to you (the set of buttons) is obviously not the same interface it presents to the remote (an infrared receiver). Figure 2.7 illustrates this.

Figure 2.7. An example of message sending from one object to another. The remote-object sends a message to the TV-object to turn itself on. The TV-object receives the message through its interface, an infrared receiver.

Back in Hour 1 . . .

You've already seen message-sending in action. In the sequence diagram in Hour 1 (Figure 1.5), the arrows represent messages that go from one object to another.

Another common occurrence is that objects are typically related to one another in some fashion. For example, when you turn on your TV, in object-oriented terms, you're in an association with your TV.

The “turn-on” association is unidirectional (one-way), as in Figure 2.8. That is, you turn your TV on. Unless you watch way too much television, however, it doesn't return the favor. Other associations, like “is married to,” are bidirectional.

Figure 2.8. Objects are often associated with each other in some way. When you turn on your TV, you're in a unidirectional association with it.

Sometimes an object might be associated with another in more than one way. If you and your coworker are friends, that's an example. You're in an “is the friend of” association, as well as an “is the coworker of” association, as Figure 2.9 shows.

Figure 2.9. Objects are sometimes associated with each other in more than one way.

A class can associate with more than one other class. A person can ride in a car, and a person can also ride in a bus (see Figure 2.10).

Figure 2.10. A class can associate with more than one other class.

Multiplicity is an important aspect of associations among objects. It tells the number of objects in one class that relate to a single object of the associated class. For example, in a typical college course, the course is taught by a single instructor. The course and the instructor are in a one-to-one association. In a proseminar, however, several instructors might teach the course throughout the semester. In that case, the course and the instructor are in a one-to-many association.

You can find all kinds of multiplicities if you look hard enough. A bicycle rides on two tires (a one-to-two multiplicity), a tricycle rides on three, and an 18-wheeler on 18.

Think about your computer system. It consists of a CPU box, a keyboard, a mouse, a monitor, a CD-ROM drive, one or more hard drives, a modem, a disk drive, a printer, and possibly some speakers. Inside the CPU box, along with the aforementioned drives, you have a CPU, a graphics card, a sound card, and some other elements you would undoubtedly find it hard to live without.

Your computer is an aggregation, another kind of association among objects. Like many other things worth having, the computer is made from a number of different types of components (see Figure 2.11). You can probably come up with numerous examples of aggregations.

Figure 2.11. A typical computer system is an example of an aggregation—an object that's made up of a combination of a number of different types of objects.

One form of aggregation involves a strong relationship between an aggregate object and its component objects. This is called composition. The key to composition is that the component exists as a component only within the composite object. For example, a shirt is a composite of a body, a collar, sleeves, buttons, buttonholes, and cuffs. Do away with the shirt and the collar becomes useless.

Sometimes a component in a composite doesn't last as long as the composite itself. The leaves on a tree can die out before the tree does. If you destroy the tree, the leaves also die (see Figure 2.12).

Figure 2.12. In a composition, a component can sometimes die out before the composite does. If you destroy the composite, you destroy the component as well.

Aggregation and composition are important because they reflect extremely common occurrences, and thus help you create models that closely resemble reality.